Re: Postgres 8.3, four times slower queries?

Поиск
Список
Период
Сортировка
От Aaron Guyon
Тема Re: Postgres 8.3, four times slower queries?
Дата
Msg-id f0afbb9b0903060750v17fff813if1cbc6df10813c48@mail.gmail.com
обсуждение исходный текст
Ответ на Postgres 8.3, four times slower queries?  (Aaron Guyon <battlemage@gmail.com>)
Список pgsql-performance
On Thu, Mar 5, 2009 at 12:58 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
What happens if you do this:

SET cpu_tuple_cost TO '0.5';
SET cpu_index_tuple_cost TO '0.5';
EXPLAIN ANALYZE 8.3 query....

Next try this:

SET cpu_tuple_cost TO '0.5';
SET cpu_index_tuple_cost TO '0.5';
SET seq_page_cost TO '4.0';
SET random_page_cost TO '1.0';
EXPLAIN ANALYZE 8.3 query....

And then this:

SET cpu_tuple_cost TO '0.5';
SET cpu_index_tuple_cost TO '0.5';
SET seq_page_cost TO '4.0';
SET random_page_cost TO '1.0';
SET effective_cache_size TO '3000MB';
EXPLAIN ANALYZE 8.3 query....

These three are pretty much the same in terms of performance.  I stayed with the first one (cpu_tuple_cost = 0.5 and cpu_index_tuple_cost = 0.5).  As shown earlier, it gives a result similar or slightly better than 8.2.12 in terms of performance and response time.  The explain analyze shows that the query no longer causes postgreSQL to uses hashes, but indexes instead which boosted the performance of the query from ~1200 ms to ~600 ms.

Thank you everyone for all the help and feedback on this issue.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Index scan plan estimates way off.
Следующее
От: Mario Splivalo
Дата:
Сообщение: Query much slower when run from postgres function