Re: Postgres 8.3, four times slower queries?

From: Aaron Guyon <battlemage(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres 8.3, four times slower queries?
Date: 2009-03-06 15:50:22
Message-ID: f0afbb9b0903060750v17fff813if1cbc6df10813c48@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Mar 5, 2009 at 12:58 PM, Joshua D. Drake <jd(at)commandprompt(dot)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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Mario Splivalo 2009-03-09 13:36:32 Query much slower when run from postgres function
Previous Message Robert Haas 2009-03-06 02:33:06 Re: Index scan plan estimates way off.