Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I think this could be done with our "SLRU" mechanism, just like pg_clog,
> pg_subtrans and pg_multixact do. Whether it's really a good idea or
> not, it's another story. The problem is that you would be creating new
> ones all the time, it would become a huge source of contention, and it
> would use a lot of memory.
... and you couldn't expire the data in a reasonable period of time.
pg_subtrans and pg_multixact have only very short active ranges.
pg_clog is longer-lived, but at only 2 bits per transaction, we can
stand it. 16 bytes per tuple is a whole lot more data.
Anyway the fundamental insight has been completely lost here. The
original point was that cmin and cmax are only interesting within the
originating transaction, and not to anyone else, and thus perhaps don't
need to be kept in permanent storage; while xmin/xmax are different
animals because they *are* of interest to other transactions.
The storage scheme Jim proposes takes no advantage of that whatever.
regards, tom lane