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 CAFjFpRex6rTHG2n+_Ai=XLRhWAXqxLpkCXFE-L3tD+rWKiWx8g@mail.gmail.com
Whole thread Raw
In response to Re: I'd like to discuss scaleout at PGCon  ("MauMau" <maumau307@gmail.com>)
Responses Re: I'd like to discuss scaleout at PGCon
Re: I'd like to discuss scaleout at PGCon
List pgsql-hackers
On Tue, Jun 5, 2018 at 10:04 PM, MauMau <maumau307@gmail.com> wrote:
> From: Ashutosh Bapat
>> 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.
>
> Yes, that's the drawback of each node in the cluster having different
> OIDs for the same object.  That applies to XL, too.

Keeping OIDs same across the nodes would require extra communication
between nodes to keep track of next OID, dropped OIDs etc. We need to
weigh the time spent in that communication and the time saved during
parsing.

>  In XL, the data
> node returns the data type names of the columns in the result set to
> the coordinator.  Then the coordinator seemed to parse each data type
> name with base_yyparse() to convert the name to its OID on the
> coordinator.  That's why base_yyparse() appeared at the top in the
> perf profile.

I do not understand, why do we need base_yyparse() to parse type name.
We already have functions specifically for parsing object names.

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


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: buildfarm vs code
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables