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:42:51
Message-ID: AANLkTinHAMZOYRTXy7UFHJ-aRO6Hxos=o9w5Dqw2he3r@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 24, 2011 at 9:39 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
>
> 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.

Or I suppose we could set the frozenxid but maintain a hash table of
relations that we use to remember which relations we created in this
transaction and are treating this way. For any table in that hash
table we ignore the xmin and just look at cmin/cmax.

I'm not sure this solves the cases of subtransactions -- but perhaps
we just wouldn't store frozenxid if we're in a subtransaction. And I'm
not sure we have access to the relation id when we're doing visibility
checks. I think we do. This would involve no serious ugliness in the
actual on-disk storage and it would make data loads a write-once
operation which is the holy grail :)

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-03-24 21:43:07 Re: Pre-set Hint bits/VACUUM FREEZE on data load..?
Previous Message Robert Haas 2011-03-24 21:41:19 Re: 2nd Level Buffer Cache