upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-02-12 23:33:27 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/include/executor/nodeBitmapAnd.h

26 lines
873 B
C
Raw Normal View History

Create executor and planner-backend support for decoupled heap and index scans, using in-memory tuple ID bitmaps as the intermediary. The planner frontend (path creation and cost estimation) is not there yet, so none of this code can be executed. I have tested it using some hacked planner code that is far too ugly to see the light of day, however. Committing now so that the bulk of the infrastructure changes go in before the tree drifts under me.
2005-04-19 18:35:18 -04:00
/*-------------------------------------------------------------------------
*
* nodeBitmapAnd.h
*
*
*
Update CVS HEAD for 2007 copyright. Back branches are typically not back-stamped for this.
2007-01-05 17:20:05 -05:00
* Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group
Create executor and planner-backend support for decoupled heap and index scans, using in-memory tuple ID bitmaps as the intermediary. The planner frontend (path creation and cost estimation) is not there yet, so none of this code can be executed. I have tested it using some hacked planner code that is far too ugly to see the light of day, however. Committing now so that the bulk of the infrastructure changes go in before the tree drifts under me.
2005-04-19 18:35:18 -04:00
* Portions Copyright (c) 1994, Regents of the University of California
*
Update CVS HEAD for 2007 copyright. Back branches are typically not back-stamped for this.
2007-01-05 17:20:05 -05:00
* $PostgreSQL: pgsql/src/include/executor/nodeBitmapAnd.h,v 1.4 2007/01/05 22:19:54 momjian Exp $
Create executor and planner-backend support for decoupled heap and index scans, using in-memory tuple ID bitmaps as the intermediary. The planner frontend (path creation and cost estimation) is not there yet, so none of this code can be executed. I have tested it using some hacked planner code that is far too ugly to see the light of day, however. Committing now so that the bulk of the infrastructure changes go in before the tree drifts under me.
2005-04-19 18:35:18 -04:00
*
*-------------------------------------------------------------------------
*/
#ifndef NODEBITMAPAND_H
#define NODEBITMAPAND_H
#include "nodes/execnodes.h"
extern int ExecCountSlotsBitmapAnd(BitmapAnd *node);
Extend the ExecInitNode API so that plan nodes receive a set of flag bits indicating which optional capabilities can actually be exercised at runtime. This will allow Sort and Material nodes, and perhaps later other nodes, to avoid unnecessary overhead in common cases. This commit just adds the infrastructure and arranges to pass the correct flag values down to plan nodes; none of the actual optimizations are here yet. I'm committing this separately in case anyone wants to measure the added overhead. (It should be negligible.) Simon Riggs and Tom Lane
2006-02-27 23:10:28 -05:00
extern BitmapAndState *ExecInitBitmapAnd(BitmapAnd *node, EState *estate, int eflags);
Create executor and planner-backend support for decoupled heap and index scans, using in-memory tuple ID bitmaps as the intermediary. The planner frontend (path creation and cost estimation) is not there yet, so none of this code can be executed. I have tested it using some hacked planner code that is far too ugly to see the light of day, however. Committing now so that the bulk of the infrastructure changes go in before the tree drifts under me.
2005-04-19 18:35:18 -04:00
extern Node *MultiExecBitmapAnd(BitmapAndState *node);
extern void ExecEndBitmapAnd(BitmapAndState *node);
extern void ExecReScanBitmapAnd(BitmapAndState *node, ExprContext *exprCtxt);
#endif /* NODEBITMAPAND_H */
Reference in a new issue Copy permalink