Re: preserving forensic information when we freeze

On Mon, Dec 23, 2013 at 10:42 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> But TBH, I'm kind of enamored of the function-based approach at the
>> moment. It just seems a lot more flexible. Adding a function is
>> nearly free and we can add as many as we need doing whatever we want,
>> and they can even go into contrib modules if we like it better that
>> way.
>
> Well, it really depends on the usecase. Reading
> SELECT header.xmin, header.xmax
> FROM sometable tbl,
> pg_tuple_header(tbl.tableoid, tbl.ctid) header;
> is surely harder to understand than
> SELECT tbl.xmin, tbl.xmax
> FROM sometable tbl;
> and the latter is noticeably cheaper since we're not re-fetching the
> tuple, especially when the tuple is the result of a more complicated
> query including a seqscan, we might often need to re-fetch the tuple
> from disk, thanks to the ringbuffer.
>
> That really makes me less than convinced that the function based
> approach is the right tool for everything.

Meh. Who are all of these people who are fetching xmin, xmax, cmin,
and cmax in complex queries, and why are they doing that? If those
columns are just for forensic purposes, then whatever performance
disadvantages the function-based approach has don't really matter. If
people are using them as integral parts of their application, then
that's more of a concern, but how are those people not getting broken
every release or three anyway? We keep inventing things like
combo-cids and multi-xacts and multi-xacts that also contain an update
and now freezing without changing xmin, and if you're actually relying
on those columns for anything but forensics your application is
presumably going to break when we change whatever part it depends on.
Is anyone really doing that, and if so, why?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company