Re: preserving forensic information when we freeze

On 2013-12-23 10:26:49 -0500, Robert Haas wrote:
> On Mon, Dec 23, 2013 at 7:45 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > I've spent some time yesterday hacking up a prototype for this. The
> > amount of effort seems reasonable, although the attached patch certainly
> > doesn't do all the neccessary things. The regression tests pass.
> 
> Well, I'm all in favor of de-bloating pg_attribute, but I don't
> particularly like cooked_xmax.  Even if it were better-named
> (updatexid?), I'm still not sure I'd like it very much.  And I
> definitely think that getting rid of the pg_attribute entries ought to
> be a separate patch from adding any new system columns we want to
> have.

Yea, that was just a demo attribute, I am far from sure we should add
any. It was just important to me to test that we're easily able to do
so. I don't even think it's semantics are necessarily all that useful.

I think we should do this, independent from adding additional
attributes. The reduction of rows in pg_attribute is quite noticeable,
and I can't see us just dropping the old system columns.

> 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.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services