Re: Optimizer degradation since 8.0

Teodor Sigaev <teodor(at)sigaev(dot)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 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