From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "S Golly" <gollykai(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: performance index scan vs bitmap-seq scan. |
Date: | 2007-12-20 22:15:36 |
Message-ID: | dcc563d10712201415l60c8fb9fv7e5723c4856a1550@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Dec 20, 2007 4:06 PM, S Golly <gollykai(at)gmail(dot)com> wrote:
> The server is running 8.2.5 FreeBSD 6.1 with 3 GB of RAM.
> I have a table with over 100M rows. I have a unique index (primary key) on
> column name called aid.
> The select count(aid) .. does a Bitmap heap scan when the right side
> condition is above 100,000,000 (if i take one zero off it does a pure index
> scan).
> My question : why is the optimizer choosing an Bitmap Heap Scan when count
> can be done with index.
Because count can't be done with the index alone.
In pgsql the visibility info is in the table itself, so even if it can
hit the index, it has to go back and hit the table to be sure if the
tuple is visible.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-12-20 22:28:21 | Re: viewing source code |
Previous Message | S Golly | 2007-12-20 22:06:55 | performance index scan vs bitmap-seq scan. |