* Greg Stark (gsstark@mit.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
