From: | Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> |
---|---|
To: | Kris Gale <krisgale(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Multicolumn index including tsvector. |
Date: | 2009-11-24 11:28:43 |
Message-ID: | 54C5FD8A-0023-49ED-BF50-6C13894E7E72@solfertje.student.utwente.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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!
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-11-24 12:14:25 | Re: [COMMITTERS] recover deleted records |
Previous Message | Matthew Wakeling | 2009-11-24 11:14:12 | Re: [PERFORM] Strange performance degradation |