On Tue, Nov 19, 2013 at 1:20 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-11-19 12:47:29 -0500, Robert Haas wrote:
>> On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > Agreed. As an alternative we could just have a single - probably longer
>> > than NAMEDATALEN - string to identify replication progress and rely on
>> > the users of the facility to build the identifier automatically
>> > themselves using components that are helpful in their system.
>>
>> I tend to feel like a generic identifier would be better. I'm not
>> sure why something like a UUID wouldn't be enough, though.
>> Arbitrary-length identifiers will be bad for performance, and 128 bits
>> ought to be enough for anyone.
>
> That's what I had suggested to some people originally and the response
> was, well, somewhat unenthusiastic. It's not that easy to assign them in
> a meaningful automated manner. How do you automatically assign a pg
> cluster an id?
/dev/urandom
> But yes, maybe the answer is to balk on that part, let the users figure
> out what's best, and then only later implement more policy based on that
> experience.
>
> 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.
I think we should also take note of Steve Singer's comments. Perhaps
this entire endeavor is premature.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
