On 2013-11-19 12:47:29 -0500, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 11:57 AM, Andres Freund <and...@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?
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

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.


Andres Freund

 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to