Re: the big picture for index-only scans - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Re: the big picture for index-only scans
Date
Msg-id CAHMh4-ZV4CbBk0FeQygN1j24g9OU-iW37WUhJXaQOO6Cg8h90g@mail.gmail.com
Whole thread Raw
In response to Re: the big picture for index-only scans  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: the big picture for index-only scans
List pgsql-hackers
>> The all_visible_cleared flag is included in the WAL record of the insert (or update or delete). Partial page
writesare not a problem, because we <br />>> always fetch the VM page and clear the bit, regardless of the LSN on
theVM page.<br /><br /><br />Two things <br />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,
thata visibility map page is getting flushed/not? With the following approach, i can see only one issue. If the heap
pagegets 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?<br /><br />b) Even if we have a contention issue, Visibility
mapis a solution for a considerable number of database scenarios. But it should not become a default package. A table,
withno chance of index-only scans should not incur the extra overhead of crash safe visibility maps. Those tables
shouldbe sparred from this extra overhead, as they don't have index only scans.<br /><br />Gokul.<br /> 

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: the big picture for index-only scans
Next
From: Gokulakannan Somasundaram
Date:
Subject: Re: the big picture for index-only scans