On Thu, Nov 21, 2013 at 8:26 AM, Andres Freund <andres@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 <andres@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
