Re: preserving forensic information when we freeze - Mailing list pgsql-hackers

From Robert Haas
Subject Re: preserving forensic information when we freeze
Date
Msg-id CA+TgmoavG+NqOR2bi_zgfV0BtW0w3=eBOdFwR=xTwjr1g3xRPg@mail.gmail.com
Whole thread Raw
In response to Re: preserving forensic information when we freeze  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: preserving forensic information when we freeze  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jan 2, 2014 at 2:44 PM, Tom Lane <tgl@sss.pgh.pa.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 making the planner
smarter about joins on CTID doesn't help a bit, unless you can push
the join qual down *inside the tuple_header_details() function call*.
That'd be pretty a pretty sweet thing to allow for SRFs in general,
but it doesn't sound like something we're going to conjure up at the
drop of a hat.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: preserving forensic information when we freeze
Next
From: Tom Lane
Date:
Subject: Re: preserving forensic information when we freeze