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