Re: Pre-set Hint bits/VACUUM FREEZE on data load..?
От | Robert Haas |
---|---|
Тема | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? |
Дата | |
Msg-id | AANLkTi=NbnjE4eTH7O49WzahbwaYomdNEygs=L2j08Ni@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Pre-set Hint bits/VACUUM FREEZE on data load..?
|
Список | pgsql-hackers |
On Thu, Mar 24, 2011 at 5:39 PM, Greg Stark <gsstark@mit.edu> wrote: > On Thu, Mar 24, 2011 at 9:15 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> On 24.03.2011 23:08, Stephen Frost wrote: >>> >>> In a discussion which came up at PgEast, I questioned if it'd be >>> possible to set the 'all visible' hint bit and give the tuples the >>> frozen XID when loading data into a table which was created in the >>> same transaction. > > Fwiw this was the original plan with Simon's patch in the 8.3 era to > skip wal logging tables being loaded in the same transaction they were > created. (Ironically often made futile by his own HS work.) There were > problems that I don't recall but might well be the same as the problem > Heikki pointed out. > >> The problem is that you still need to track which queries within the >> transaction can see the tuples. > > We could conceivably deal with that by not setting the frozenxid but > setting the hint bit for those tuples and having a documented special > case that if the hint bit is set but it's the same xid as your own you > have to treat it as not-committed. > > Not sure if it's worth the ugliness to solve only half the problem. I > get the impression most people are complaining about hint bit setting > i/o but if you're still going to have to rewrite the table at some > time in the future the problem's not really resolved. Also, you're not really going to get the whole benefit unless you can somehow manage to mark the pages PD_ALL_VISIBLE and set the visibility map bits. Without that, the next vacuum is going to dirty the whole heap anyway. Granted that's a bit better than having the next scan do it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: