Re: Same query, same performance

From: "Josh Berkus" <josh(at)agliodbs(dot)com>
To: "alexandre :: aldeia digital" <alepaes(at)aldeiadigital(dot)com(dot)br>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Same query, same performance
Date: 2003-01-23 17:00:02
Message-ID: web-2323224@davinci.ethosmedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Alexandre,

> I have a system with 7 Million of records in 600 tables.
> My actual production machine is: P4 1.6G, 3 IDE 7200, 1GB PC133
> My new machine production is: Dual Xeon 2.0G HT, 1GB DDR266 ECC
> 3 SCSI with HW Raid 5

Well, first of all, those two systems are almost equivalent as far as
Postgres is concerned for simple queries. The extra processor power
will only help you with very complex queries. 3-disk RAID 5 is no
faster ... and sometimes slower ... than IDE for database purposes.
The only real boost to the Xeon is the faster RAM ... which may not
help you if your drive array is the bottleneck.

>
> The postgresql.conf is the SAME in both systems and I test
> with no other connections, only my local test.
>
> shared_buffers = 80000
> effective_cache_size = 60000
> random_page_cost = 2.5
> cpu_tuple_cost = 0.001
> cpu_index_tuple_cost = 0.0001
> cpu_operator_cost = 0.00025

Not that it affects the query below, but what about SORT_MEM?

> If I execute the same query executed a lot of times, the
> duration is praticaly the same in both systems ?
>
> 1) ! 1.185424 elapsed 1.090000 user 0.100000 system sec
> 2) ! 1.184415 elapsed 1.070000 user 0.120000 system sec
> 3) ! 1.185209 elapsed 1.100000 user 0.080000 system sec
>
> If the disks is not read directly, the system must find
> the rows in RAM. If it find in RAM, why so diffrents machines
> have the times of execution and why the times does not down ???

I'm pretty sure that PostgreSQL always checks on disk, even when the
same query is run repeatedly. Tom?

> [postgres(at)host1 data]$ psql -c "explain SELECT T2.fi15emp05,
> T2.fi15flagcf, T2.fi15codcf, T1.Fn06Emp07, T1.Fn06TipTit,
> T1.Fn06TitBan,
> T1.Fn06Conta1, T1.Fn06NumTit, T1.Fn06Desdob, T1.Fn05CodPre,
> T1.Fn06eCli1,
> T1.Fn06tCli1, T1.Fn06cCli1, T2.fi15nome FROM (FN06T T1 LEFT JOIN
> FI15T
> T2 ON T2.fi15emp05 = T1.Fn06eCli1 AND T2.fi15flagcf = T1.Fn06tCli1
> AND
> T2.fi15codcf = T1.Fn06cCli1) WHERE ( T1.Fn06Emp07 = '1' AND
> T1.Fn06TipTit = 'R' ) AND ( T1.Fn06TitBan = '002021001525
>
> ' ) ORDER BY T1.Fn06Emp07, T1.Fn06TipTit, T1.Fn06NumTit,
> T1.Fn06Desdob,
> T1.Fn05CodPre, T1.Fn06eCli1, T1.Fn06tCli1, T1.Fn06cCli1" Pro13Z

Actually, from your stats, Postgres is doing a pretty good job. 1.18
seconds to return 15 rows from a 7 million row table searching on not
Indexed columns? I don't think you have anything to complain about.

If you want less-than-1 second respose time: Add some indexes and keep
the tables VACUUMed so the indexes work. Particularly, add a
multi-column index on ( T1.Fn06Emp07, T1.Fn06TipTit, T1.Fn06TitBan )

If you want single-digit-msec response: Get a better disk set for
Postgres: I recommend dual-channel RAID 1 (n addition to indexing).

-Josh Berkus

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Hannu Krosing 2003-01-23 17:42:26 Re: Terrible performance on wide selects
Previous Message Chantal Ackermann 2003-01-23 15:52:51 Re: [PERFORM] optimizing query