Re: I'd like to discuss scaleout at PGCon
От | MauMau |
---|---|
Тема | Re: I'd like to discuss scaleout at PGCon |
Дата | |
Msg-id | ADEBE3E2F49F45B1898869CB81698F3A@tunaPC обсуждение исходный текст |
Ответ на | Re: I'd like to discuss scaleout at PGCon (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | 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 -----Original Message----- From: Ashutosh Bapat Sent: Saturday, June 2, 2018 1:00 AM To: Tom Lane Cc: MauMau ; Robert Haas ; PostgreSQL Hackers Subject: Re: I'd like to discuss scaleout at PGCon 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 по дате отправления: