Re: Planner hints in Postgresql
От | Claudio Freire |
---|---|
Тема | Re: Planner hints in Postgresql |
Дата | |
Msg-id | CAGTBQpaModPwpyc5iGNvWBaBohZAnkOn-1aPKokbOm_UxT9fvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Planner hints in Postgresql (Jim Nasby <jim@nasby.net>) |
Ответы |
Re: Planner hints in Postgresql
|
Список | pgsql-hackers |
<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Mon, Mar 17, 2014 at 7:09 PM, Jim Nasby <span dir="ltr"><<ahref="mailto:jim@nasby.net" target="_blank">jim@nasby.net</a>></span> wrote:<br /><blockquote class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 3/17/14, 2:16 PM,Merlin Moncure wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 17, 2014 at 1:45 PM, Pavel Stehule<<a href="mailto:pavel.stehule@gmail.com" target="_blank">pavel.stehule@gmail.<u></u>com</a>> wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px#ccc solid;padding-left:1ex"> >I don't believe so SELECTIVITY can work well too. Slow queries areusually<br /> >related to some strange points in data. I am thinking so well concept should<br /> >be based on validityof estimations. Some plans are based on totally wrong<br /> >estimation, but should be fast due less sensitivityto bad estimations. So<br /> >well concept is penalization some risk plans - or use brute force - like<br />>COLUMN store engine does. Their plan is usually simply and tolerant to bad<br /> >estimations.<br /></blockquote>Disagree. There is a special case of slow query where problem is not<br /> with the data but with the expressionover the data; something in the<br /> query defeats sampled selectivity. Common culprits are:<br /><br /> *) CASEexpressions<br /> *) COALESCE<br /> *) casts<br /> *) simple tranformational expressions<br /> *) predicate string concatenation<br/></blockquote><br /></div> *) time/date functions, ie WHERE date_trunc( 'quarter', some_timestamp ) = '2014-1-1'<br/><br /> Though, in this case it's probably much better to teach the parser how to turn that into a range expression.</blockquote></div><br/><br /></div><div class="gmail_extra">Maybe, maybe not.<br /><br /></div><div class="gmail_extra">An index over the truncated time can potentially be much more efficient.<br /></div></div>
В списке pgsql-hackers по дате отправления: