| From: | "Ow Mun Heng" <ow(dot)mun(dot)heng(at)wdc(dot)com> |
|---|---|
| To: | "Matthew Wakeling" <matthew(at)flymine(dot)org> |
| Cc: | "Thomas Finneid" <tfinneid(at)fcon(dot)no>, "Greg Smith" <gsmith(at)gregsmith(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: increase index performance |
| Date: | 2009-05-14 11:54:20 |
| Message-ID: | D1109E8B2FB53A45BDB60F8145905CE901DDB7B2@wdmyexbe03.my.asia.wdc.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
-----Original Message-----
From: Matthew Wakeling [mailto:matthew(at)flymine(dot)org]
On Thu, 14 May 2009, Ow Mun Heng wrote:
>> Shouldn't BITMAP indexes come into play?
>>
>> Does having one index w/ 3 parameters being better than 3 index w/ 3
>> different parameters be better for BITMAP index seeks?
>I'll let someone correct me if I'm wrong, but using a single index that
>exactly covers your search is always going to be better than munging
>together results from several indexes, even if the planner decides to turn
>it into a bitmap index scan (which will be more likely in PG8.4 with
>effective_concurrency set).
I don't dis-agree there, but for multiple field indexes, the sequence has to
be followed. If queries hit those exact sequence, then we're good to go, if
not, then it's wasted and not used to it's full capability.
Effective_concurrency you say.. Hmm... gotta goggle that
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brad Jorsch | 2009-05-14 14:37:04 | UNION ALL and sequential scans |
| Previous Message | Matthew Wakeling | 2009-05-14 10:20:33 | Re: increase index performance |