Re: Plans for solving the VACUUM problem

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> In fact, multi-query transactions are just a special case of
> subtransactions, where all previous subtransactions are
> committed/visible. We could use the same pg_log-style memory area for
> multi-query transactions, eliminating the command counter and saving 8
> bytes overhead per tuple.

Interesting thought, but command IDs don't act the same as transactions;
in particular, visibility of one scan to another doesn't necessarily
depend on whether the scan has finished.

Possibly that could be taken into account by having different rules for
"do we think it's committed" in the local pg_log than the global one.

Also, this distinction would propagate out of the xact status code;
for example, it wouldn't do for heapam to set the "known committed"
bit on a tuple just because it's from a previous subtransaction of the
current xact. Right now that works because heapam knows the difference
between xacts and commands; it would still have to know the difference.

A much more significant objection is that such a design would eat xact
IDs at a tremendous rate, to no purpose. CommandCounterIncrement is a
cheap operation now, and we do it with abandon. It would not be cheap
if it implied allocating a new xact ID that would eventually need to be
marked committed. I don't mind allocating a new xact ID for each
explicitly-created savepoint, but a new ID per CommandCounterIncrement
is a different story.

regards, tom lane