Re: query planning different in plpgsql?

Поиск
Список
Период
Сортировка
От Waldomiro
Тема Re: query planning different in plpgsql?
Дата
Msg-id 4AE5FEDC.6050102@shx.com.br
обсуждение исходный текст
Ответ на Re: query planning different in plpgsql?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Try to force a unique plan, like that:<br /><br /> SELECT field, field2 ...<br /> FROM table1<br /> WHERE field3 =
'xxx'<br/> AND field4 = 'yyy'<br /> AND field5 = 'zzz'<br /><br /> so, in that example, I need the planner to use my
field4index, but the planner insists to use the field5, so I rewrite the query like this:<br /><br /> SELECT field,
field2...<br /> FROM table1<br /> WHERE trim(field3) = 'xxx'<br /> AND field4 = 'yyy'<br /> AND trim(field5) = 'zzz'<br
/><br/> I  didn´t give any option to the planner, so I get what plan I want.<br /><br /> Waldomiro<br /><br /><br />
TomLane escreveu: <blockquote cite="mid:13574.1256580589@sss.pgh.pa.us" type="cite"><pre wrap="">"Michal J. Kubski" <a
class="moz-txt-link-rfc2396E"href="mailto:michal.kubski@cdt.pl"><michal.kubski@cdt.pl></a> writes:
</pre><blockquotetype="cite"><pre wrap="">[ function that creates a bunch of temporary tables and immediately
 
joins them ]   </pre></blockquote><pre wrap="">
It'd probably be a good idea to insert an ANALYZE on the temp tables
after you fill them.  The way you've got this set up, there is no chance
of auto-analyze correcting that oversight for you, so the planner will
be planning the join "blind" without any stats.  Good results would only
come by pure luck.
        regards, tom lane
 </pre></blockquote><br />

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: query planning different in plpgsql?
Следующее
От: Jesper Krogh
Дата:
Сообщение: bitmap heap scan way cheaper than seq scan on the same amount of tuples (fts-search).