Re: Sub-optimal plan chosen
От | bricklen |
---|---|
Тема | Re: Sub-optimal plan chosen |
Дата | |
Msg-id | 33b743250909100825p6a8a4e5ay19a846f303a5b7a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Sub-optimal plan chosen (tv@fuzzy.cz) |
Ответы |
Re: Sub-optimal plan chosen
|
Список | pgsql-performance |
Hi Tomas,
2009/9/10 <tv@fuzzy.cz>
Playing around with seq_page_cost (1) and random_page_cost (1), I can get the correct index selected. Applying those same settings to our production server does not produce the optimal plan, though.
> default_statistics_target = 100 (tried with 500, no change). VacuumModifying the statistics target is useful only if the estimates are
> analyzed
> before initial query, and after each change to default_statistics_target.
seriously off, which is not your case - so it won't help, at least not
reliably.Yes, the difference between costs of the two plans is quite small (11796
> The same query, with a different "ofid", will occasionally get the more
> optimal plan -- I assume that the distribution of data is the
> differentiator
> there.
vs. 13153) so it's very sensible to data distribution.You may try to play with the 'cost' constants - see this:
> Is there any other data I can provide to shed some light on this?
http://www.postgresql.org/docs/8.4/interactive/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
You just need to modify them so that the bitmap index scan / bitmap heap
scan is prefered to plain index scan.
Just be careful - if set in the postgresql.conf, it affects all the
queries and may cause serious problems with other queries. So it deserves
proper testing ...
regards
Tomas
Playing around with seq_page_cost (1) and random_page_cost (1), I can get the correct index selected. Applying those same settings to our production server does not produce the optimal plan, though.
В списке pgsql-performance по дате отправления: