From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical column ordering |
Date: | 2015-04-14 21:43:54 |
Message-ID: | CA+TgmobSFhtisMg6yL8kDjjcL-K2-YXav+JyRLaPaV9zo+w+Kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 14, 2015 at 2:38 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> As I said, I'm still writing the first pieces of this so I'm not sure
> what other ramifications it will have. If there are any thoughts, I
> would appreciate them. (Particularly useful input on whether it is
> acceptable to omit lognums/physnums from _outRangeTblEntry.)
I think the general rule is that an RTE should not contain any
structure information about the underlying relation that can
potentially change: the OID is OK because it's immutable for any given
relation. The relkind is not quite immutable because you can create a
_SELECT rule on a table and turn it into a view; I'm not sure how we
handle that, but it's a fairly minor exception anyhow. Everything
else in the RTE, with the new and perhaps-unfortunate exception of
security quals, is stuff derived from what's in the query, not the
table. I think it would be good for this to work the same way: the
structural information about the table should be found in the
relcache, not the RTE.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2015-04-14 22:07:51 | Re: Turning off HOT/Cleanup sometimes |
Previous Message | Robert Haas | 2015-04-14 21:25:31 | Re: Clock sweep not caching enough B-Tree leaf pages? |