From: | Tels <nospam-pg-abuse(at)bloodgate(dot)com> |
---|---|
To: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: Speed up Hash Join by teaching ExprState about hashing |
Date: | 2024-08-17 11:21:03 |
Message-ID: | 527bc1b5de6345c9fb34b6a8d76b6eb7@bloodgate.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello David,
you wrote:
> v4 patch attached. If nobody else wants to look at this then I'm
> planning on pushing it soon.
Had a very brief look at this bit caught my attentioon:
+ EEO_CASE(EEOP_HASHDATUM_NEXT32_STRICT)
+ {
+ FunctionCallInfo fcinfo = op->d.hashdatum.fcinfo_data;
+ uint32 existing_hash = DatumGetUInt32(*op->resvalue);
+ uint32 hashvalue;
+
+ /* combine successive hash values by rotating */
+ existing_hash = pg_rotate_left32(existing_hash, 1);
+
+ if (fcinfo->args[0].isnull)
+ {
Is it nec. to rotate existing_hash here before checking for isnull?
Because in case of isnull, isn't the result of the rotate thrown away?
Or in other words, mnaybe this bit here can be moved to after the isnull
check:
+ /* combine successive hash values by rotating */
+ existing_hash = pg_rotate_left32(existing_hash, 1);
--
Best regards,
Tels
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2024-08-17 11:59:34 | Re: Opinion poll: Sending an automated email to a thread when it gets added to the commitfest |
Previous Message | Thomas Munro | 2024-08-17 09:44:26 | Re: Opinion poll: Sending an automated email to a thread when it gets added to the commitfest |