Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
От | Robert Haas |
---|---|
Тема | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL |
Дата | |
Msg-id | CA+TgmoZXSncyq50H7WRSS3uxoyQ_dy21c8Ew2HiGkrqOwE9J2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: 9.2.1 & index-only scans : abnormal heap fetches
after VACUUM FULL
|
Список | pgsql-hackers |
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Thu, Nov 28, 2013 at 05:38:05PM -0500, Bruce Momjian wrote: >> > 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! > > So, should I put this in the next commit fest? +1. > I still have an unknown > about the buffer number to use here: > > ! /* XXX use 0 or real offset? */ > ! ItemPointerSet(&(tuple.t_self), BufferIsValid(buf) ? > ! BufferGetBlockNumber(buf) : 0, offnum); > > Is everyone else OK with this approach? Updated patch attached. I started looking at this a little more the other day but got bogged down in other things before I got through it all. I think we're going to want to revise this so that it doesn't go through the functions that current assume that they're always deal with a shared_buffer, but I haven't figured out exactly what the most elegant way of doing that is yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: