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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Pre-set Hint bits/VACUUM FREEZE on data load..?
Date: 2011-03-25 11:49:33
Message-ID: 20110325114933.GM4116@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Greg Stark (gsstark(at)mit(dot)edu) wrote:
> 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.

This was exactly where I was going, and, honestly, I was wondering if
there'd be a way to possibly even avoid running through
HeapTupleIsVisible for those relations entirely.. Up to the point where
some further action modifies the table again and forces us to have to go
through that path.

I'm not sure I feel it's a real 'bad' hack. :)

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

Right, that kind of issue is why I had been thinking it might be a
different mode, but it also may not be all that bad to use an approach
like what you described above. We could descide to not do it for
temporary tables, perhaps, or, if we could possibly avoid having to
check for visibility at the tuple level for these relations, perhaps
it'd be faster on those use-cases..?

We would need to figure out, also, if people are doing batch
operations.. eg: they load 10000 records at a time into a table. We
wouldn't want to lose these optimizations in those cases, provied
they're done one after another.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2011-03-25 11:53:15 Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous Message Greg Stark 2011-03-25 11:41:28 Re: Pre-set Hint bits/VACUUM FREEZE on data load..?