Scott Marlowe pisze:
2010/5/14 Piotr Legiecki <piotrlg@xxxxxxxxxxxxxxxxxxx>:
So what is the problem? My simple 'benchmarks' I have done with pgAdmin in
spare time.
pgAdmin is the latest 1.8.2 on both D and E.
Using pgAdmin on my (D) computer I have run SELECT * from some_table; and
noted the execution time on both A and B servers:
So, any chance you'll run it like I asked:
select count(*) from some_table;
Sorry, but it was computer-less weekend ;-)
So to answer all questions in one mail:
1. The database is autovacuumed, at first (the default debian setting)
every one minute, than I have set it to one hour.
2. select count(*) from some_table; runs in a fraction of a second on
the console on both servers (there are only 4000 records, the second
longer table has 50000 but it does not matter very much). From pg_admin
the results are:
- slow server (and the longest table in my db) 938ms (first run) and
about 40ms next ones
- fast server 110ms first run, about 30ms next ones.
Well, finally my new server deservers its name ;-) The later times as I
understand are just cache readings from postgresql itself?
3. The configs. As noted earlier, at first test they were the same,
later I started to optimize the faster server from the defaults to some
higher values, without any significant gain.
The package on slower server is just deb package from etch (4.0)
repository, the one on fast server (which is newer lenny - 5.0) is
compiled from deb source package on that server.
fast server: http://pgsql.privatepaste.com/edf2ec36c3
slow server: http://pgsql.privatepaste.com/bdc141f0be
4. Machine. The new server has 5 SAS disks (+ 1 spare), but I don't
remember how they are set up now (looks like mirror for system '/' and
RAID5 for rest - including DB). size of the DB is 405MB
So still I don't get this: select * from table; on old server takes 0,5
sec, on new one takes 6sec. Why there is so big difference? And it does
not matter how good or bad select is to measure performance, because I
don't measure the performance, I measure the relative difference.
Somwhere there is a bottleneck.
Regards
P.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
