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
> wrote:
> > Is it possible to f
On Fri, Oct 3, 2014 at 6:38 PM, Andrey Lizenko wrote:
> 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 c
Hi,
I have similar problem as in
http://www.postgresql.org/message-id/flat/52b311c4.1070...@gmail.com#52b311c4.1070...@gmail.com
server version is 9.3.4
Here is only two quite simple tables:
db_new=# \d activities_example
Table "public.activities_example"
Column | Type | Modifiers
As I answered to Tom few moments ago:
>reducing 'random_page_cost' from 2 to 1 and increasing
'effective_cache_size' from 70% to 80% of RAM solved this at least on my
virtual sandbox.
I've observed same behaviour both on weak virtual machine and on the quite
powerfull stress test platform.
The firs
Thanks a lot, Tom,
reducing 'random_page_cost' from 2 to 1 and increasing 'effective_cache_size'
from 70% to 80% of RAM solved this at least on my virtual sandbox.
By the way, why increasing of cache only (with the same random_page_cost=2) can
lead to mergejoin selection?
On 5 October 2014 23:47,
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;" ?
Disabling hashjoins altogether would be a pretty dangerous "fix".
I think the real issue h
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 increasing `work_mem` should have effects, as plan with `Nested
Loop` is using disk-based
Hi,
I have similar problem as in
http://www.postgresql.org/message-id/flat/52b311c4.1070...@gmail.com#52b311c4.1070...@gmail.com
server version is 9.3.4
Here is only two quite simple tables:
db_new=# \d activities_example
Table "public.activities_example"
Column | Type | Modifiers
