Re: crash-safe visibility map, take three
От | Heikki Linnakangas |
---|---|
Тема | Re: crash-safe visibility map, take three |
Дата | |
Msg-id | 4CF65348.7070903@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: crash-safe visibility map, take three (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: crash-safe visibility map, take three
Re: crash-safe visibility map, take three |
Список | pgsql-hackers |
On 01.12.2010 15:39, Bruce Momjian wrote: > Heikki Linnakangas wrote: >> On 01.12.2010 03:35, Bruce Momjian wrote: >>> Heikki Linnakangas wrote: >>>> Let's recap what happens when a VM bit is set: You set the >>>> PD_ALL_VISIBLE flag on the heap page (assuming it's not set already, it >>>> usually isn't), and then set the bit in the VM while keeping the heap >>>> page locked. >>> >>> What if we set PD_ALL_VISIBLE on the heap page, wait for a checkpoint to >>> happen so the heap page is guaranteed to be on disk, then on next read, >>> if PD_ALL_VISIBLE is set and the VM all-visible bit is not set, set the >>> VM bit. >> >> Hmm, you'd somehow have to know if a checkpoint has happened since the >> flag was set. And it might be a long wait, which makes it less > > Well, doesn't the page LSN tell you that already? If we update the LSN when we set the flag, then we have to write the full-page-image. That's very expensive. If we don't update the LSN, then the LSN says nothing about when the flag was set. >> attractive for index-only scans. > > My assumption is that this page will remain read-only for a while, so I > don't see the big downside in a delay of max 5-10 minutes. For sites > where pages go frequently in and out of read-only status, I don't think > index-only scans are every going to be a big win. Long-running queries > alone are going to delay how quickly we can set PD_ALL_VISIBLE, so I > don't see an additional 5-10 minutes as a big problem. Perhaps we could live with it, but it would be annoying to have to checkpoint after a data load, before index-only scans kick in. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: