Re: Same query, same performance

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Same query, same performance
Дата
Msg-id web-2323224@davinci.ethosmedia.com
обсуждение исходный текст
Ответ на Same query, same performance  ("alexandre :: aldeia digital" <alepaes@aldeiadigital.com.br>)
Ответы Re: Same query, same performance  ("alexandre :: aldeia digital" <alepaes@aldeiadigital.com.br>)
Список 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@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



В списке pgsql-performance по дате отправления:

Предыдущее
От: Curt Sampson
Дата:
Сообщение: Re: [HACKERS] Terrible performance on wide selects
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: [HACKERS] Terrible performance on wide selects