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  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          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?"