> The most significant impact is that it takes up twice as much space, > including the primary key index. This means fewer entries per block, > which means slower scans and/or more blocks to navigate through. Still, > compared to the rest of the overhead of an index row or a table row, it > is low - I think it's more important to understand whether you can get > away with using a sequential integer, in which case UUID is unnecessary > overhead - or whether you are going to need UUID anyways. If you need > UUID anyways - having two primary keys is probably not worth it. Ok, that's what I was hoping. Out of curiosity, is there a preferred way to store 256-bit ints in postgres? At that point, is a bytea the most reasonable choice, or is there a better way to do it? -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
