Thanks for reply, sir.
On 11/21/2016 1:39 AM, Tom Lane wrote:
Man writes:
Additional information.
In 9.6 the second table (lesser tuple) was choosen (the same testdata).
There are something (cost estimation?) different in previous versions.
I'd bet on different statistics in the two installa
Man writes:
> Additional information.
> In 9.6 the second table (lesser tuple) was choosen (the same testdata).
> There are something (cost estimation?) different in previous versions.
I'd bet on different statistics in the two installations (either you
forgot to ANALYZE, or the random sample ca
Thanks for response, sir.
On 11/20/2016 1:18 AM, Tom Lane wrote:
Man Trieu writes:
As in the example below, i think the plan which hash table is created on
testtbl2 (the fewer tuples) should be choosen.
The planner usually prefers to hash on the table that has a flatter
MCV histogram, since a
Man Trieu writes:
> As in the example below, i think the plan which hash table is created on
> testtbl2 (the fewer tuples) should be choosen.
The planner usually prefers to hash on the table that has a flatter
MCV histogram, since a hash table with many key collisions will be
inefficient. You mi
Hi Experts,
As in the example below, i think the plan which hash table is created on
testtbl2 (the fewer tuples) should be choosen.
Because creating of hash table should faster in testtbl2. But it did not.
I have tried to change the ordering of table by tuning parameter even if
using pg_hint_plan
