Moving to -hackers
I was asking about how to distinguish the index cost component of an indexscan
from the cost of heap.
https://www.postgresql.org/message-id/20200103141427.GK12066%40telsasoft.com
On Fri, Jan 03, 2020 at 09:33:35AM -0500, Jeff Janes wrote:
> > It would help to be able to set enable_bitmapscan=FORCE (to make all index
> > scans go through a bitmap).
>
> Doesn't enable_indexscan=off accomplish this already? It is possible but
> not terribly likely to switch from index to seq, rather than from index to
> bitmap. (Unless the index scan was being used to obtain an ordered result,
> but a hypothetical enable_bitmapscan=FORCE can't fix that).
No, enable_indexscan=off implicitly disables bitmap index scans, since it does:
cost_bitmap_heap_scan():
|startup_cost += indexTotalCost;
But maybe it shouldn't (?) Or maybe it should take a third value, like
enable_indexscan=bitmaponly, which means what it says. Actually the name is
confusable with indexonly, so maybe enable_indexscan=bitmap.
A third value isn't really needed anyway; its only utility is that someone
upgrading from v12 who uses enable_indexscan=off (presumably in limited scope)
wouldn't have to also set enable_bitmapscan=off - not a big benefit.
That doesn't affect regress tests at all.
Note, when I tested it, the cost of "bitmap heap scan" was several times higher
than the total cost of indexscan (including heap), even with CPU costs at 0. I
applied my "bitmap correlation" patch, which seems to gives more reasonable
result. In any case, the purpose of this patch was primarily diagnostic, and
the heap cost of index scan would be its total cost minus the cost of the
bitmap indexscan node when enable_indexscan=off. The high cost attributed to
bitmap heapscan is topic for the other patch.
Justin