Re: [PERFORM] query plan question, nested loop vs hash join

2014-10-08 Thread Andrey Lizenko
Thanks for your reply, Marti, as I answered to Tom couple of days ago adjusting of 'effective_cache_size' to 80% of RAM and 'random_page_cost' from 2 to 1 helped me. On 8 October 2014 00:26, Marti Raudsepp wrote: > On Fri, Oct 3, 2014 at 6:38 PM, Andrey Lizenko > wr

[PERFORM] query plan question, nested loop vs hash join

2014-10-07 Thread Andrey Lizenko
le" in the first case? Is it possible to force optimizer choose the second plan without doing "set enable_hashjoin = off;" ? Increasing of 'effective_cache_size' leads to similar thing with mergejoin, other options (work_mem, shared_buffers. etc) do not change anything. Thanks in advance. -- Regards, Andrey Lizenko

Re: [PERFORM] query plan question, nested loop vs hash join

2014-10-06 Thread Andrey Lizenko
2014 23:18, Victor Yegorov wrote: > 2014-10-05 21:57 GMT+03:00 Andrey Lizenko : > >> Increasing of 'effective_cache_size' leads to similar thing with >> mergejoin, >> other options (work_mem, shared_buffers. etc) do not change anything. >> > > I think i

Re: [PERFORM] query plan question, nested loop vs hash join

2014-10-06 Thread Andrey Lizenko
5 October 2014 23:47, Tom Lane wrote: > Andrey Lizenko writes: > > What is the reason of "Seq Scan on activities_example" in the first case? > > Is it possible to force optimizer choose the second plan without doing > > "set enable_hashjoin = off;" ? &

[PERFORM] query plan question, nested loop vs hash join

2014-10-05 Thread Andrey Lizenko
le" in the first case? Is it possible to force optimizer choose the second plan without doing "set enable_hashjoin = off;" ? Increasing of 'effective_cache_size' leads to similar thing with mergejoin, other options (work_mem, shared_buffers. etc) do not change anything. Thanks in advance. -- Regards, Andrey Lizenko