Re: I'd like to discuss scaleout at PGCon - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: I'd like to discuss scaleout at PGCon
Date
Msg-id CAFjFpReniXHLdpQyOG=ohX08_3gGuYvn2vfLz3a+Oa1z_EsYuw@mail.gmail.com
Whole thread Raw
In response to Re: I'd like to discuss scaleout at PGCon  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: I'd like to discuss scaleout at PGCon
Re: I'd like to discuss scaleout at PGCon
List pgsql-hackers
On Fri, Jun 1, 2018 at 11:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
>> In order to avoid double parsing, we might want to find a way to pass
>> a "normalized" parse tree down to the foreign server. We need to
>> normalize the OIDs in the parse tree since those may be different
>> across the nodes.
>
> I don't think this is a good idea at all.  It breaks any hope of
> supporting remote servers that are not the identical version to the local
> one (since their parsetrees might be different).  And "normalized OIDs"
> sounds like "pie in the sky".  You might get away with asssuming that
> built-in functions have stable OIDs, but you can't expect that for
> functions in extensions.

Sorry for confusing writeup. I didn't mean "normalized OIDs" as I
mentioned in my last sentence. I meant "normalized parse-tree" as in
the first sentence. In order to normalize parse trees, we need to at
least replace various OIDs in parse-tree with something that the
foreign server will understand correctly like table name on the
foreign table pointed to by local foreign table OR (schema qualified)
function names  and so on. There might be more things to "normalize"
in the parse tree other than OIDs, but I can't think of anything right
now.


-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: I'd like to discuss scaleout at PGCon
Next
From: Pavel Stehule
Date:
Subject: Re: why partition pruning doesn't work?