On Tue, Nov 19, 2013 at 1:20 PM, Andres Freund <and...@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 <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?
/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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
