From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? |
Date: | 2011-03-24 21:43:07 |
Message-ID: | AANLkTi=NbnjE4eTH7O49WzahbwaYomdNEygs=L2j08Ni@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 24, 2011 at 5:39 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Thu, Mar 24, 2011 at 9:15 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-03-24 21:43:39 | Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause, |
Previous Message | Greg Stark | 2011-03-24 21:42:51 | Re: Pre-set Hint bits/VACUUM FREEZE on data load..? |