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  (Jim Nasby <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Planner hints in Postgresql
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Planner hints in Postgresql