From: | Dawid Kuroczko <qnex42(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | integer[] indexing. |
Date: | 2004-10-08 09:11:16 |
Message-ID: | 758d5e7f041008021163fb40eb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I have a large table with a column:
ids integer[] not null
most of these entries (over 95%) contain only one array element, some
can contain up to 10 array elements. seqscan is naturally slow. GIST
on int_array works nice, but GIST isn't exactly a speed daemon when it
comes to updating.
So I thought, why not create partial indexes?
CREATE INDEX one_element_array_index ON table ((ids[1])) WHERE icount(ids) <= 1;
CREATE INDEX many_element_array_index ON table USING GIST (ids) WHERE
icount(ids) > 1;
Now, if I select WHERE icount(ids) <= 1 AND ids[1] = 33 I get
lightning fast results.
If I select WHERE icount(ids) > 1 AND ids && '{33}' -- I get them even faster.
But when I phrase the query:
SELECT * FROM table WHERE (icount(ids) <= 1 AND ids[1] = 33) OR
(icount(ids) > 1 AND ids && '{33}');
Planner insists on using seqscan. Even with enable_seqscan = off;
Any hints, comments? :) [ I think thsese partial indexes take best of
two worlds, only if planner wanted to take advantage of it... :) ]
Regards,
Dawid
From | Date | Subject | |
---|---|---|---|
Next Message | Pierre-Frédéric Caillaud | 2004-10-08 09:29:35 | Re: integer[] indexing. |
Previous Message | Pierre-Frédéric Caillaud | 2004-10-08 08:54:59 | Re: sequential scan on select distinct |