Re: I'd like to discuss scaleout at PGCon

From: "MauMau" <maumau307(at)gmail(dot)com>
To: "Ashutosh Bapat" <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: I'd like to discuss scaleout at PGCon
Date: 2018-06-05 16:34:20
Message-ID: 63F9D3119E8941A9BFFF8377ED95D703@tunaPC
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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. That repeated typename-to-OID conversion would be
reduced by caching the conversion result, like the logical replication
of PostgreSQL does. But managing the catalog at one place and using
the same OID values seems to concise to me as a concept.

Regards
MauMau

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message MauMau 2018-06-05 16:36:35 Re: I'd like to discuss scaleout at PGCon
Previous Message Emre Hasegeli 2018-06-05 16:32:59 Re: [PATCH] Improve geometric types