Re: Optimizer degradation since 8.0

Teodor Sigaev <teodor@sigaev.ru> 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
indexscansinternal to a single IndexScanplan node, as this behavior is now better done as a bitmap ORindexscan.  This
allowsconsiderable simplification innodeIndexscan.c itself as well as several planner modules concernedwith indexscan
plangeneration.  Also we can improve the sharing ofcode between regular and bitmap indexscans, since they are
nowworkingwith 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