Thanks for the reply. On Oct 2, 2015, at 3:26 PM, Jim Nasby wrote: > I'm not really following here... the size of an index is determined by the number of tuples in it and the average width of each tuple. So as long as you're using the same size of data type, 18 vs 1 sequence won't change the size of your indexes. I'm pretty much concerned with exactly that -- the general distribution of numbers, which affects the average size/length of each key. Using an even distribution as an example, the average width of the keys can increase by 2 places: Since we have ~18 object types, the primary keys in each might range from 1 to 9,999,999 Using a shared sequence, the keys for the same dataset would range from 1 to 189,999,999 Each table is highly related, and may fkey onto 2-4 other tables... So i'm a bit wary of this change. But if it works for others... I'm fine with that! > Sequences are designed to be extremely fast to assign. If you ever did find a single sequence being a bottleneck, you could always start caching values in each backend. I think it'd be hard (if not impossible) to turn a single global sequence into a real bottleneck. I don't think so either, but everything I've read has been theoretical -- so I was hoping that someone here can give the "yeah, no issue!" from experience. The closest production stuff I found was via the BDR plugin (only relevant thing that came up during search) and there seemed to be anecdotal accounts of issues with sequences becoming bottlenecks -- but that was from their code that pre-generated allowable sequence ids on each node. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
