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
