Re: getting rid of freezing
От | Robert Haas |
---|---|
Тема | Re: getting rid of freezing |
Дата | |
Msg-id | CA+Tgmobn4qjsT5esEOhSaUSxyk3wMBFtM60SbARbEEMw-Ud9LA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: getting rid of freezing (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: getting rid of freezing
Re: getting rid of freezing |
Список | pgsql-hackers |
On Fri, May 24, 2013 at 10:53 AM, Andres Freund <andres@2ndquadrant.com> wrote: >> [all-visible cannot restore hint bits without FPI because of torn pages] > > I haven't yet thought about this sufficiently yet. I think we might have > a chance of working around this, let me ponder a bit. Yeah. I too feel like there might be a solution. But I don't know have something specific in mind, yet anyway. > But even if that means needing a full page write via the usual mechanism > for all visible if any hint bits needed to be set we are still out far > ahead of the current state imo. > * cleanup would quite possibly do an FPI shortly after in vacuum > anyway. If we do it for all visible, it possibly does not need to be > done for it. > * freezing would FPI almost guaranteedly since we do it so much > later. > * Not having to rescan the whole heap will be a bigger cost saving... The basic problem is that if the data is going to be removed before it would have gotten frozen, then the extra FPIs are just overhead. In effect, we're just deciding to freeze a lot sooner. And while that might well be beneficial in some use cases (e.g. the data's already in cache) it might also not be so beneficial (the table is larger than cache and would have been dropped before freezing kicked in). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: