- 23 5月, 2006 1 次提交
-
-
由 Tom Lane 提交于
any use in the past many years, we'd have made some effort to include them in all executor node types; but in fact they were only in nodeAppend.c and nodeIndexscan.c, up until I copied nodeIndexscan.c's occurrence into the new bitmap node types. Remove some other unused macros in execdebug.h, too. Some day the whole header probably ought to go away in favor of better-designed facilities.
-
- 05 3月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 28 2月, 2006 1 次提交
-
-
由 Tom Lane 提交于
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
-
- 15 10月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 29 8月, 2005 1 次提交
-
-
由 Tom Lane 提交于
got an empty bitmap after any step; the remaining subplans can no longer affect the result. Per a suggestion from Ilia Kantor.
-
- 20 4月, 2005 2 次提交
-
-
由 Tom Lane 提交于
bitmaps for multiple indexscans. Instead just let each indexscan add TIDs directly into the BitmapOr node's result bitmap.
-
由 Tom Lane 提交于
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.
-