From: | Man <man(dot)trieu(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: How to change order sort of table in HashJoin |
Date: | 2016-11-21 13:12:13 |
Message-ID: | c52861b0-0c72-c2ed-9704-eea7d5664bfc@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Thanks for reply, sir.
On 11/21/2016 1:39 AM, Tom Lane wrote:
> Man <man(dot)trieu(at)gmail(dot)com> 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 came up quite a bit different).
> And I'm a little suspicious that these tests weren't all done with the
> same work_mem setting.
I dumped the two tables in pg9.4 and restored to pg9.6, sir.
I also set default_statistics_target to 1000 and ANALYZE d two tables in
both installations.
And so that were result.
Anyway i know that order can not change by tuning parameters because it
depend on storing data, thanks.
> regards, tom lane
Thanks and best regards,
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Anns | 2016-11-21 13:15:17 | Re: How the Planner in PGStrom differs from PostgreSQL? |
Previous Message | azhwkd | 2016-11-21 12:57:44 | query locks up when run concurrently |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2016-11-21 13:29:57 | Re: Improvements in psql hooks for variables |
Previous Message | Ashutosh Bapat | 2016-11-21 13:02:12 | Re: Push down more full joins in postgres_fdw |