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.
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. |