Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
От | Bruce Momjian |
---|---|
Тема | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |
Дата | |
Msg-id | 20131128223805.GC20216@momjian.us обсуждение исходный текст |
Ответ на | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: 9.2.1 & index-only scans : abnormal heap fetches
after VACUUM FULL
|
Список | pgsql-hackers |
On Thu, Nov 28, 2013 at 05:17:07PM -0500, Robert Haas wrote: > > I need to know this is the right approach, and need to know what things > > are wrong or missing. > > The fact that you've needed to modify SetHintBits() to make this work > is pretty nasty. I'm not exactly sure what to do about that, but it > doesn't seem good. Hey, if that's the worst of the problems, I will be very happy. There is a sense that because we are not using the shared buffer cache and not WAL logging, we have to skip some stuff. > This patch also has the desirable but surprising consequence that hint > bits will be set as a side effect of update_page_vm(), which means > that you'd better do that BEFORE checksumming the page. Yes, I already saw that and fixed it in my git tree. > I wonder if we ought to mark each page as all-visible in > raw_heap_insert() when we first initialize it, and then clear the flag > when we come across a tuple that isn't all-visible. We could try to > set hint bits on the tuple before placing it on the page, too, though > I'm not sure of the details. I went with the per-page approach because I wanted to re-use the vacuum lazy function. Is there some other code that does this already? I am trying to avoid yet-another set of routines that would need to be maintained or could be buggy. This hit bit setting is tricky. And thanks much for the review! -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: