On Wed, Jun 6, 2018 at 8:16 PM, MauMau <maumau307@gmail.com> wrote:
> From: Ashutosh Bapat
>> 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.
>
> If we manage the system catalog for cluster-wide objects (tables,
> indexes, databases, users, and almost all other objects) on one
> central node, and separate the OID space for cluster-wide objects from
> that for the node-local objects (temporary tables, tablespaces, and
> what else?), we don't need to keep track of OIDs across nodes.
>
I think that will lead to many more network trips to the central node
in order to fetch OIDs of various objects. We could reduce that by
using node local caches but still invalidation messages will eat some
bandwidth. The network trips in this case may be more than what are
required for keeping track of OID space across nodes. Do you see
something like this in similar other products?
>
>>> 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.
>
> Looking at the XL source code, the following sequence of functions are
> called when the coordinator handles the Row Description message ('T')
> from the data node. I guess the parsing is necessary to process type
> names combined with type modifiers, e.g. "char(100)".
>
> create_tuple_desc
> parseTypeString
> typeStringToTypeName
> raw_parser
>
Hmm, strange. I had not seen that in Postgres-XC.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company