From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:48:41 |
Message-ID: | CA+TgmoavG+NqOR2bi_zgfV0BtW0w3=eBOdFwR=xTwjr1g3xRPg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-02 19:52:33 | Re: preserving forensic information when we freeze |
Previous Message | Tom Lane | 2014-01-02 19:44:34 | Re: preserving forensic information when we freeze |