Re: Pre-set Hint bits/VACUUM FREEZE on data load..?

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

In response to

Responses

Browse pgsql-hackers by date

  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..?