Re: the big picture for index-only scans

>> The all_visible_cleared flag is included in the WAL record of the insert
(or update or delete). Partial page writes are not a problem, because we
>> always fetch the VM page and clear the bit, regardless of the LSN on the
VM page.

Two things
a) First, my understanding of checkpoint is that it flushes all the pages,
that got changed below a particular LSN. If we are not having a LSN in the
visibility map, how we will be sure, that a visibility map page is getting
flushed/not? With the following approach, i can see only one issue. If the
heap page gets written and checkpointed and the visibility map doesn't get
synced during the checkpoint, then there is an issue. Can you please explain
me, how we get the assurance?

b) Even if we have a contention issue, Visibility map is a solution for a
considerable number of database scenarios. But it should not become a
default package. A table, with no chance of index-only scans should not
incur the extra overhead of crash safe visibility maps. Those tables should
be sparred from this extra overhead, as they don't have index only scans.

Gokul.