Re: review: FDW API

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jan Urbański <wulczer(at)wulczer(dot)org>
Subject: Re: review: FDW API
Date: 2011-02-18 15:47:21
Message-ID: 22262.1298044041@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-02-18 15:51:47 Re: Debian readline/libedit breakage
Previous Message Andrew Dunstan 2011-02-18 15:42:20 Re: Debian readline/libedit breakage