Re: Speed up Hash Join by teaching ExprState about hashing

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: nospam-pg-abuse(at)bloodgate(dot)com, Alexey Dvoichenkov <alexey(at)hyperplane(dot)net>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Speed up Hash Join by teaching ExprState about hashing
Date: 2024-11-05 01:10:48
Message-ID: CAApHDvpMAL_zxbMRr1LOex3O7Y7R7ZN2i8iUFLQhqQiJMAg3qw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 20 Aug 2024 at 13:40, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> I made a few more tweaks to the comments and pushed the result.

While working on the patch to make HashAgg / hashed subplans and
hashed setops to use ExprState hashing, I discovered a bug in that
code when hashing 0 hashkeys (Possible with SELECT FROM t INTERSECT
SELECT FROM t;) where the initial value wasn't being stored properly.
I was storing it in the intermediate hash location expecting that the
step to process the final hash key would fetch that and store the
final result in ExprState.resvalue. That's clearly not going to work
when there are 0 expressions to hash. The correct thing to do is just
store the initial value in the ExprState.resvalue field directly when
there are zero expressions to hash.

The attached patch fixes the same mistake in ExecBuildHash32Expr().
This bug is only hypothetical as currently, nothing calls that
function passing a non-zero initial value.

I plan on pushing this shortly.

David

Attachment Content-Type Size
0001-Fix-hypothetical-bug-in-ExprState-building-for-hashi.patch text/plain 3.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-11-05 01:12:58 Re: general purpose array_sort
Previous Message Michael Paquier 2024-11-05 00:43:11 Re: Clear padding in PgStat_HashKey keys