Re: optimize hashjoin

On Fri, Aug 23, 2024 at 08:17:26AM -0400, Robert Haas wrote:
> 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.

Where are we on this patch?

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"