On 2013-12-20 07:12:01 -0500, Robert Haas wrote: > I think the root of the problem is that nobody's very eager to add > more hidden system catalog columns because each one bloats > pg_attribute significantly.
I think that part is actually solveable - there's no real need for them to be real columns, present in pg_attribute, things could easily enough be setup during parse analysis. The bigger problem I see is that adding more useful columns will cause name clashes, which will probably prohibit improvements in that direction. > Maybe what we should do is add a function something like > pg_tuple_header(tableoid, ctid) that returns a record, maybe something > like (rawxmin xid, rawxmax xid, rawcid cid, infomask int, infomask2 > int, hoff int). Or perhaps some slightly more cooked version of that > information. And then delete the xmin, xmax, cmin, and cmax system > columns. That'd save significantly on pg_attribute entries while, at > the same time, actually providing more information than we do today. I was wondering whether we couldn't just pass pg_tuple_header() a whole row, instead of having the user manually pass in reloid and ctid. I think that should actually work in the interesting scenarios. > pageinspect is useful, too, but it seems to deal mostly with pages, so > I'm not sure it's a natural substitute for something like this. Agreed. I also think that we really need something to investigate problems in core, not in a contrib module people won't have installed, especially in bigger setups. That said I plan to either submit some improvements to pageinspect myself, or convince somebody else to do so in the not too far away future. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
