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-25 11:41:28
Message-ID: AANLkTikuy=j3mhjD2zR4hq694yX_wvQ6jkbEFTU6irwG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 25, 2011 at 8:09 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> The tricky part here is how to check if the table was created in the same
> transaction, within HeapTupleSatisfiesMVCC, with minimal overhead. If you do
> it naively, the check will be executed at every single tuple read in the
> system. It has to be really really fast.
>

You could have a single global boolean variable to indicate whether
any tables have been created in this transaction and inserted into
using this frozenxid hack in this transaction yet. That would be
branch predicted as false in any decent processor which shouldn't cost
anything. If it's true then you go off and check a small hash table.

The question is how often would the insert trigger with false
positives. That is, how often do people create tables, insert a small
number of records, then go off and do complex performance-sensitive
things in the same transaction. I suppose this does happen due to the
fairly common pattern of "I want temporary tables but they need to be
visible to this other transaction". For example for batch jobs where
you want to be able to display some sort of progress indicator.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2011-03-25 11:49:33 Re: Pre-set Hint bits/VACUUM FREEZE on data load..?
Previous Message Cédric Villemain 2011-03-25 10:50:36 Re: really lazy vacuums?