On 24 Nov 2009, at 24:08, Kris Gale wrote: > Table "public.example" > Column | Type | Modifiers > ---------+----------+----------- > body | text | > vectors | tsvector | > user_id | bigint | > > I've got btree_gin and btree_gist installed, so I can make a composite index > on vectors and user_id (which is a bigint).
A bigint for userid? How many billions of users do you expect to get? A bigint is 8 bytes or 64 bits. I think a normal int (32-bits) would be quite sufficient; it allows up to 2 billion users. It uses less storage space for both the data and the indices too. And as Tom already said casting can be a problem with bigints, not only if certain operators aren't defined for comparison between int and bigint, but you'll also see a performance hit if table data you compare to needs to be upcasted to a bigint; joins come to mind. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:737,4b0bc36e11738279827033! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
