Re: I'd like to discuss scaleout at PGCon
От | MauMau |
---|---|
Тема | Re: I'd like to discuss scaleout at PGCon |
Дата | |
Msg-id | 82580DF0FEE54F3AA979646D16440BEE@tunaPC обсуждение исходный текст |
Ответ на | Re: I'd like to discuss scaleout at PGCon (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: I'd like to discuss scaleout at PGCon
|
Список | pgsql-hackers |
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. >> 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 Regards MauMau
В списке pgsql-hackers по дате отправления: