Re: Hash join in 8.3

Поиск
Список
Период
Сортировка
От André Volpato
Тема Re: Hash join in 8.3
Дата
Msg-id 4761A442.8090600@ecomtecnologia.com.br
обсуждение исходный текст
Ответ на Re: Hash join in 8.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Hash join in 8.3  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-general
Tom Lane escreveu: <blockquote cite="mid:18544.1197574622@sss.pgh.pa.us" type="cite"><pre wrap="">Gregory Stark <a
class="moz-txt-link-rfc2396E"href="mailto:stark@enterprisedb.com"><stark@enterprisedb.com></a> writes:
</pre><blockquotetype="cite"><pre wrap="">But I'm curious if you turn off mergejoin whether you can get a Nested Loop
 
plan and what cost 8.3 gives it. It looks to me like 8.3 came up with a higher
cost for Nested Loop than 8.1.9 (I think 8.1.10 came out with some planner
fixes btw) and so it's deciding these other plans are better. And they might
have been better for the imaginary scenario that the planner thinks is going
on.   </pre></blockquote><pre wrap="">
Actually, now that I think about it, 8.3 should be *more* likely than
8.1 to choose a nestloop-with-inner-indexscan plan.  8.1 didn't have the
changes to allow a discount for repeated inner indexscans.

I'm wondering if

(a) the 8.1 installation being compared to had some planner cost
parameter changes that were not copied into the 8.3 installation; or

(b) the only reason 8.1 likes the nestloop plan is that it has no
statistics on the test tables, whereas 8.3 does have stats because
of autovacuum being on by default.
        regards, tom lane </pre></blockquote><br /> I think I found the answer!<br /><br /> 8.1: likes nested loop even
aftervacuumdb on the database.<br /><br /> 8.3: likes hash at first time but:<br /> - after vacuumdb *on the database*
(Iwas running on the tables.....), it turns out to:<br />  Merge Join  (cost=178779.93..328503.44 rows=30000 width=38)
in20005.207 ms<br /> #set enable_mergejoin=off;<br />  Hash Join  (cost=156644.00..365204.03 rows=30000 width=38) in
29104.390ms<br />  * a very faster hash here, seqscanning the smaller table before the bigger one. Tricky!<br /><br />
Iwont trust table vacuums anymore...<br /><br /><pre class="moz-signature" cols="72">-- 
 

[]´s,

André Volpato
Ecom Tecnologia LTDA - Análise e Desenvolvimento
<a class="moz-txt-link-abbreviated"
href="mailto:andre.volpato@ecomtecnologia.com.br">andre.volpato@ecomtecnologia.com.br</a></pre>

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

Предыдущее
От: Andreas Kretschmer
Дата:
Сообщение: Re: data type change on a view
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: Hash join in 8.3