* Heikki Linnakangas (heikki.linnakangas@enterprisedb.com) wrote:
> The problem is that you still need to track which queries within the
> transaction can see the tuples. For example:
Alright, one final thought on this for a while..
We can check if the table was created in the current transaction. If it
was, no tuples in it could possibly be frozen, except if we set them
that way when we first loaded them. How about something of the form:
At the start of a load, we check if the table was created in the current
transaction. If so, we check if we've already done a load which used
the frozen XID. If we have, then we use the normal mechanics. If we
havn't, then we stuff what the XID would have been in memory somewhere,
mark that we've used the frozen XID, and load the data using the frozen
XID. On subsequent queries, if we come across a frozen XID in a table
created in this transaction, we use the XID we've stored instead of the
frozen XID.
The gist of this being that we could avoid having to rewrite the table
while still tracking what the XID would have been for these records for
subsequent activities. I certainly like something similar to this
better than the "disable thing we think might break", since that could
change over time and we may implement something new that breaks and we
forgot to add it to the exclude list. Additionally, having an 'include'
list for the data loading mode wouldn't be ideal if we can avoid it, but
if not, may be acceptable anyway to get the fast path.
My concern here and what I see the counter-argument being (presuming
this isn't completely insane anyway) is added cost when we're not in
this mode (tho hopefully an extra compare won't be too expensive
overall..) and perhaps an issue with where the code would have to go to
implement this and violating abstraction layers, etc.
Headed back to pgEast. :)
Thanks,
Stephen
