Whoops, wrong thread. On Mon, May 17, 2010 at 2:52 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > On Mon, May 17, 2010 at 2:10 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: >> On Mon, May 17, 2010 at 2:06 AM, Piotr Legiecki <piotrlg@xxxxxxxxxx> wrote: >>> 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? >> SNIP >>> So the server itself seems faster. >>> 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. >> >> Yep, the network I'd say. How fast are things like scp between the >> various machines? >> >>> 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 >> >> Get off of RAID-5 if possible. A 3 Disk RAID-5 is the slowest >> possible combination for RAID-5 and RAID-5 is generally the poorest >> choice for a db server. > > I refer you to this classic post on the subject: > http://www.mail-archive.com/pgsql-general@xxxxxxxxxxxxxx/msg93043.html -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
