Re: 8.3devel slower than 8.2 under read-only load
От | Guillaume Smet |
---|---|
Тема | Re: 8.3devel slower than 8.2 under read-only load |
Дата | |
Msg-id | 1d4e0c10711211701u4b52ad89ibfda3a10f28e21c8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 8.3devel slower than 8.2 under read-only load (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: 8.3devel slower than 8.2 under read-only load
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: