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
meant5X per byte rather than 5X per tuple.
I talked this over with Haas, and his opinion is that we have a LOT of overhead in the way we transverse indexes,
especiallylookups which happen once per leaf node instead of in bulk. Certainly the performance I'm seeing would be
consistentwith that idea.
I'll try some multi-column covering indexes next to see how it looks.
----- Original Message -----
> On Thu, May 17, 2012 at 5:22 AM, Joshua Berkus <josh@agliodbs.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
>
