| 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 18:53:51 |
| Message-ID: | CAMkU=1wV+n6B+38_N=d6UKB56EPvUU1VOxqOVDx3hzhH9c-0-A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 17, 2012 at 11:35 AM, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:
> Jeff,
>
> That's in-RAM speed ... I ran the query twice to make sure the index was cached, and it didn't get any better. And I meant 5X per byte rather than 5X per tuple.
Ah, OK that makes more sense. I played around with this, specifically
count(*), quite a bit when IOS first came out, and I attributed a
large part of the time to the code that forms a tuple out of raw
bytes, and the code that advances the aggregate. The first one is
probably more a per-tuple cost than per byte, and the second
definitely is per tuple cost.
I can't find my detailed notes from this work, so this is just from memory.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Berkus | 2012-05-17 18:57:33 | Re: Strange issues with 9.2 pg_basebackup & replication |
| Previous Message | Joshua Berkus | 2012-05-17 18:35:14 | Re: Why is indexonlyscan so darned slow? |