From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Joshua Berkus <josh(at)agliodbs(dot)com> |
Cc: | Ants Aasma <ants(at)cybertec(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why is indexonlyscan so darned slow? |
Date: | 2012-05-17 16:26:24 |
Message-ID: | CAMkU=1woatEkfHguEiLF3zFYhrf2OKUGpXLV_07uQEwShoL8Jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 17, 2012 at 5:22 AM, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:
> Ants,
>
> Well, that's somewhat better, but again hardly the gain in performance I'd expect to see ... especially since this is ideal circumstances for index-only scan.
>
> bench2=# select count(*) from pgbench_accounts;
> count
> ----------
> 20000000
> (1 row)
>
> Time: 3827.508 ms
>
> bench2=# set enable_indexonlyscan=off;
> SET
> Time: 0.241 ms
> bench2=# select count(*) from pgbench_accounts;
> count
> ----------
> 20000000
> (1 row)
>
> Time: 16012.444 ms
>
> For some reason counting tuples in an index takes 5X as long (per tuple) as counting them in a table. Why?
>
It looks like the IOS is taking 4x less time, not more time.
Anyway, the IOS follows the index logical structure, not the physical
structure, so if the index is not in RAM it will really be hurt by the
lack of sequential reads.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2012-05-17 16:27:58 | Re: Strange issues with 9.2 pg_basebackup & replication |
Previous Message | Stephen Frost | 2012-05-17 15:30:25 | Re: Pre-alloc ListCell's optimization |