Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> On 15.02.2011 23:00, Tom Lane wrote:
>> I think moving the error check downstream would be a good thing.
> Ok, I tried moving the error checks to preprocess_rowmarks().
> Unfortunately RelOptInfos haven't been built at that stage yet, so you
> still have to do the catalog lookup to get the relkind. That defeats the
> purpose.
Mph. It seems like the right fix here is to add relkind to
RangeTblEntry: it could be filled in for free in addRangeTableEntry, for
example. The main downside of that is that relation relkinds would have
to become fixed (because there would be no practical way of updating
RTEs in stored rules), which means the "convert relation to view" hack
would have to go away. Offhand I think no one cares about that anymore,
but ...
In any case, this is looking like a performance optimization that should
be dealt with in a separate patch. I'd suggest leaving the code in the
form with the extra relkind lookups for the initial commit. It's
possible that no one would notice the extra lookups anyway --- have you
benchmarked it?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
