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

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: 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:39:05
Message-ID: AANLkTimCBugHJJPT-u95R+9d0TqDCf32r8t3Ad9PoLWo@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-03-24 21:41:19 Re: 2nd Level Buffer Cache
Previous Message Greg Stark 2011-03-24 21:34:55 Re: 2nd Level Buffer Cache