From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Jim Nasby <jim(at)nasby(dot)net> |
Subject: | Re: preserving forensic information when we freeze |
Date: | 2014-01-02 14:49:27 |
Message-ID: | 20140102144927.GB842@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-01-02 09:40:54 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, Jan 2, 2014 at 12:26 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
> >> 1) it's a bit weird to go to this effort to eliminate system columns by
> >> using a scheme that depends on having a system column -- ctid
>
> > At any rate, my goal isn't really to get rid of system columns, but to
> > address Jim Nasby's gripe that the changes thus far committed make it
> > difficult to use system columns to determine whether a given tuple has
> > been frozen. It sounds like the consensus is that a system column is
> > a better way of doing that than a function, so I suppose the next step
> > is to try to hammer out the details.
>
> Actually, I thought the function approach was a good proposal. You are
> right that func(tab.*) isn't going to work, because it's going to get a
> Datum-ified tuple not a pointer to raw on-disk storage. But an inspection
> function that's handed a ctid could work.
Well, we discussed that upthread, and the overhead of going through a
function is quite noticeable because the tuple needs to be fetched from
the heap again.
Check http://archives.postgresql.org/message-id/CA%2BTgmoYdWOZa_UiewbqE73AQCM2etpMjukkcmYPkGatH8kPTow%40mail.gmail.com
To get rid of part of the performance problem, we could possibly invent
a way to pass a HeapTuple instead of a blessed HeapTupleHeader to
functions, but that might not be so easy.
> And I really really *don't* want to see us bloating pg_attribute, nor
> infringing further on application column namespace, by adding even more
> exposed columns. So -1 for just blindly doing that.
Upthread there's a POC patch of mine, that started to explore what's
necessary to simply never store system columns (except maybe oid) in
pg_attribute. While it passes the regression tests it's not complete,
but the amount of work looks reasonable. Check
http://archives.postgresql.org/message-id/20131223124504.GB19795%40alap2.anarazel.de
Now, that obviously doesn't get rid of the namespace problem. I'd
suggested a system: prefix, Robert _pg_. Neither is pretty, but imo
should work.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-01-02 16:08:33 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Previous Message | Tom Lane | 2014-01-02 14:40:54 | Re: preserving forensic information when we freeze |