Re: Multicolumn index including tsvector.

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!

In response to

Browse pgsql-general by date

  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