Re: the big picture for index-only scans
От | Gokulakannan Somasundaram |
---|---|
Тема | Re: the big picture for index-only scans |
Дата | |
Msg-id | CAHMh4-ZV4CbBk0FeQygN1j24g9OU-iW37WUhJXaQOO6Cg8h90g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: the big picture for index-only scans (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: the big picture for index-only scans
|
Список | 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 по дате отправления: