Re: Are bitmap index scans slow to start?

From: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Are bitmap index scans slow to start?
Date: 2013-02-21 19:40:59
Message-ID: B6F6FD62F2624C4C9916AC0175D56D8801B17F@jenmbs01.ad.intershop.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


>Rebuilding the index might help, as it would put all the leaf pages holding values for session_id=27 adjacent to each other, so they would read from disk faster. But with a name like >"session_id", I don't know how long such clustering would last though.

>If I'm right about the index disk-read time, then switching to a plain index scan rather than a bitmap index scan would make no difference--either way the data has to come off the disk.

>>I'd prefer a
>>strategy that allowed fast performance the first time, rather than slow the
>>first time and extremely fast subsequently.

Hello,

if the index is only used to locate rows for single session_id, you may consider split it in a set of partial indexes.

e.g.
create index i_0 on foo where session_id%4 =0;
create index i_1 on foo where session_id%4 =1;
create index i_2 on foo where session_id%4 =2;
create index i_3 on foo where session_id%4 =3;

(can be built in parallel using separate threads)

Then you will have to ensure that all your WHERE clauses also contain the index condition:

WHERE session_id = 27 AND session_id%4 =27%4

regards,

Marc Mamin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Alexander Staubo 2013-02-21 19:44:27 Bad query plan with high-cardinality column
Previous Message Jeff Janes 2013-02-21 18:19:54 Re: Are bitmap index scans slow to start?