Re: preserving forensic information when we freeze

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(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 19:56:16
Message-ID: 14451.1388692576@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jan 2, 2014 at 2:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> As I commented to Robert, the page-at-a-time behavior of pageinspect
>> is not an API detail we'd want to copy for this. I envision something
>> like
>>
>> select hdr.*, foo.*
>> from tuple_header_details('foo'::regclass) as hdr
>> left join foo on hdr.ctid = foo.ctid;
>>
>> On a large table you might want a version that restricts its scan
>> to pages M through N, but that's just optimization. More useful
>> would be to improve the planner's intelligence about joins on ctid ...

> /me blinks.

> Surely you're not serious. That's going to scan the whole darn table
> even if we only want the details for one row.

And? The complaint about the other function was that it was inefficient
when getting the details for a whole table, so I don't think you can
complain about an approach that handles that case well. Use the other
function if you just want info for one row (that you can see).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-01-02 19:58:54 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Previous Message David Rowley 2014-01-02 19:53:16 Re: [PATCH] Negative Transition Aggregate Functions (WIP)