On Wed, Mar 6, 2019 at 11:41 PM Heikki Linnakangas <hlinn...@iki.fi> wrote: > I don't understand it :-(. I guess that's valuable feedback on its own. > I'll spend more time reading the code around that, but meanwhile, if you > can think of a simpler way to explain it in the comments, that'd be good.
One more thing on this: If you force bitmap index scans (by disabling index-only scans and index scans with the "enable_" GUCs), then you get EXPLAIN (ANALYZE, BUFFERS) instrumentation for the index alone (and the heap, separately). No visibility map accesses, which obscure the same numbers for a similar index-only scan. You can then observe that most searches of a single value will touch the bare minimum number of index pages. For example, if there are 3 levels in the index, you should access only 3 index pages total, unless there are literally hundreds of matches, and cannot avoid storing them on more than one leaf page. You'll see that the scan touches the minimum possible number of index pages, because of: * Many duplicates strategy. (Not single value strategy, which I incorrectly mentioned in relation to this earlier.) * The !minusinfykey optimization, which ensures that we go to the right of an otherwise-equal pivot tuple in an internal page, rather than left. * The "continuescan" high key patch, which ensures that the scan doesn't go to the right from the first leaf page to try to find even more matches. The high key on the same leaf page will indicate that the scan is over, without actually visiting the sibling. (Again, I'm assuming that your search is for a single value.) -- Peter Geoghegan
