Re: I'd like to discuss scaleout at PGCon - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: I'd like to discuss scaleout at PGCon
Date
Msg-id 20180606181623.7czy5e2jycc7bjcj@alvherre.pgsql
Whole thread Raw
In response to Re: I'd like to discuss scaleout at PGCon  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: I'd like to discuss scaleout at PGCon
Re: I'd like to discuss scaleout at PGCon
Re: I'd like to discuss scaleout at PGCon
List pgsql-hackers
On 2018-Jun-06, Ashutosh Bapat wrote:

> 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.

We already have the ability to give objects some predetermined OID, for
pg_upgrade.

Maybe an easy (hah) thing to do is use 2PC for DDL, agree on a OID
that's free on every node, then create the object in all servers at the
same time.  We currently use the system-wide OID generator to assign the
OID, but seems an easy thing to change (much harder is to prevent
concurrent creation of objects using the arranged OID; maybe can reuse
speculative tokens in btrees for this).  Doing this imposes a cost at
DDL-execution-time only, which seems much better than imposing the cost
of translating name to OID on every server for every query.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: POC: GROUP BY optimization
Next
From: Heikki Linnakangas
Date:
Subject: Pushing down join clauses into subqueries