From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tim Kane <tim(dot)kane(at)gmail(dot)com> |
Cc: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Convincing the query planner to play nice |
Date: | 2013-08-11 00:38:43 |
Message-ID: | 29212.1376181523@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tim Kane <tim(dot)kane(at)gmail(dot)com> writes:
> I guess the clustering approach managed to work around the need to mess with the statistics target. I did previously increase the target to 1000 (from 100) for that field and had no impact, but this is an aspect of tuning I'm not so familiar with - I didn't consider pushing it all the way to 11.
Yeah, I had actually started to write an email recommending that you dial
down effective_cache_size and increase random_page_cost, before I noticed
the discrepancy in the merge join cost and realized what was really going
on.
The question now is why you had those settings like that before, and
whether changing them back in the direction of the defaults might not be
pessimizing the behavior for other queries. If you have a lot of RAM and
mostly-cached queries, the previous settings didn't sound unreasonable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Kane | 2013-08-11 01:03:08 | Re: Convincing the query planner to play nice |
Previous Message | Tim Kane | 2013-08-11 00:29:32 | Re: Convincing the query planner to play nice |