On Nov 22, 2007 12:49 AM, Greg Smith <gsmith@gregsmith.com> wrote:
> Hard drives deliver a higher transfer rate at their inner
> portions, typically the start of the disk from the operating system's
> perspective.
It could have been a good point if it was seq scans of large tables.
It's only index scans on small tables which return only a couple of
rows. They all fit in cache without any problem.
For the last test I exposed in a previous email, the table is just
5480 rows and here are the sizes of the table and the index used:
cityvox=> select pg_size_pretty(pg_relation_size('vilsitelang'));pg_size_pretty
----------------232 kB
(1 row)
cityvox=> select pg_size_pretty(pg_relation_size('pk_vilsitelang'));pg_size_pretty
----------------120 kB
(1 row)
> Not saying this is responsible for your results, just that benchmarking is
> hard and there may be somthing other than what you think responsible for a
> difference of this size.
Sure. That's why I wanted other people advice :).
I'm not saying my benchmark is perfectly relevant: I made it
excessively simple on purpose. I just see a general slow down which is
quite consistent accross all the tests I did (with pgbench or the
application) and I'd really like to know if it's just my case on this
particular box or something more general.
Let's call it a call to share benchmark results for 8.3 :). We're not
that far from the release and I didn't see a lot of benchmarks results
around.
I just wanted to add that I know that there is a lot of other things
which may be faster with 8.3. What bothers me is that I don't think
the other improvements will help that much this database in particular
and this is by far the most critical database we're hosting here.
--
Guillaume
