From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | bucoo <bucoo(at)sohu(dot)com> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: optimize hashjoin |
Date: | 2024-08-23 12:17:26 |
Message-ID: | CA+TgmoY-Ksqax_BRyTpKTT9Qy-_wQ7W7gveSOLJLQkAn=RJ46w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 23, 2024 at 7:02 AM bucoo <bucoo(at)sohu(dot)com> wrote:
> Howerver, the non-parallel hashjoin indeed showed about a 10% performance improvement.
> -> Hash Join (cost=508496.00..2302429.31 rows=47989008 width=0) (actual time=1075.213..9503.727 rows=47989007 loops=1)
> -> Hash Join (cost=508496.00..2302429.31 rows=47989008 width=0) (actual time=1087.588..8726.441 rows=47989007 loops=1)
It's not a good idea to test performance with EXPLAIN ANALYZE,
generally speaking. And you usually need to test a few times and
average or something, rather than just a single test. But also, this
doesn't show the hash join being 10% faster. It shows the hash join
being essentially the same speed (1075ms unpatched, 1087ms patched),
and the aggregate node on top of it being faster.
Now, it does seem possible to me that changing one node could cause a
performance improvement for the node above it, but I don't quite see
why that would happen in this case.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Anthonin Bonnefoy | 2024-08-23 12:22:25 | Re: Segfault in jit tuple deforming on arm64 due to LLVM issue |
Previous Message | Heikki Linnakangas | 2024-08-23 12:04:30 | Re: Redundant assignment of table OID for a HeapTuple? |