Teodor Sigaev <[EMAIL PROTECTED]> writes: > Can I tweak something in 8.1 or it's a bug?
It's not a bug, it's an intentional change: 2005-04-24 21:30 tgl * src/: backend/commands/explain.c, backend/executor/nodeBitmapIndexscan.c, backend/executor/nodeIndexscan.c, backend/nodes/copyfuncs.c, backend/nodes/outfuncs.c, backend/optimizer/path/allpaths.c, backend/optimizer/path/indxpath.c, backend/optimizer/path/orindxpath.c, backend/optimizer/plan/createplan.c, backend/optimizer/plan/setrefs.c, backend/optimizer/plan/subselect.c, backend/optimizer/util/pathnode.c, backend/optimizer/util/restrictinfo.c, backend/utils/adt/selfuncs.c, include/executor/nodeIndexscan.h, include/nodes/execnodes.h, include/nodes/plannodes.h, include/nodes/relation.h, include/optimizer/paths.h, include/optimizer/planmain.h, include/optimizer/restrictinfo.h: Remove support for OR'd indexscans internal to a single IndexScan plan node, as this behavior is now better done as a bitmap OR indexscan. This allows considerable simplification in nodeIndexscan.c itself as well as several planner modules concerned with indexscan plan generation. Also we can improve the sharing of code between regular and bitmap indexscans, since they are now working with nigh-identical Plan nodes. Your example shows a case where a plain indexscan's zero startup cost is very useful. I'm disinclined to revert the above patch completely, because the OR'd-indexscan code was a mess, but perhaps we could consider ways to make bitmap scans start delivering tuples sooner than after finishing the whole index scan. Not for 8.2 though :-( regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly