On Thu, Nov 21, 2013 at 8:26 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-11-21 08:22:05 -0500, Robert Haas wrote: >> On Thu, Nov 21, 2013 at 6:15 AM, Andres Freund <and...@2ndquadrant.com> >> wrote: >> >> > WRT performance: I agree that fixed-width identifiers are more >> >> > performant, that's why I went for them, but I am not sure it's that >> >> > important. The performance sensitive parts should all be done using the >> >> > internal id the identifier maps to, not the public one. >> >> >> >> But I thought the internal identifier was exactly what we're creating. >> > >> > Sure. But how often are we a) going to create such an identifier b) >> > looking it up? >> >> Never. Make that the replication solution's problem. Make the core >> support deal only with UUIDs or pairs of 64-bit integers or something >> like that, and let the replication solution decide what they mean. > > I think we're misunderstanding each other. I was commenting on your fear > that strings longer than NAMEDATALEN or something would be bad for > performance - which I don't think is very relevant because the lookups > from "public" to "internal" identifier shouldn't be in any performance > critical path. > > I personally would prefer a string because it'd allow me to build an > identifier using the criterions I'd originally outlined outside of this > infrastructure.
Yeah, there's some confusion here. I don't care at all about the performance characteristics of long strings here, because we shouldn't be using them anywhere in the core code. What I do care about is making sure that whatever core support we use here is agnostic to how the internal identifiers - relatively short bit strings - are generated. The patch as proposed puts forward a particular way of doing that, and I think that neither that method *nor any other* should be part of core. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
