Re: increase index performance - Mailing list pgsql-performance

From Ow Mun Heng
Subject Re: increase index performance
Date
Msg-id D1109E8B2FB53A45BDB60F8145905CE901DDB7B2@wdmyexbe03.my.asia.wdc.com
Whole thread Raw
In response to Re: increase index performance  (Matthew Wakeling <matthew@flymine.org>)
List pgsql-performance

-----Original Message-----
From: Matthew Wakeling [mailto:matthew@flymine.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


pgsql-performance by date:

Previous
From: Matthew Wakeling
Date:
Subject: Re: increase index performance
Next
From: "Brad Jorsch"
Date:
Subject: UNION ALL and sequential scans