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