Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>, James Coleman <jtc331@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-11-10T23:44:38Z
Lists: pgsql-bugs
On Sun, Nov 10, 2019 at 02:46:31PM -0800, Andres Freund wrote: >Hi, > >On 2019-11-10 22:50:17 +0100, Tomas Vondra wrote: >> On Sun, Nov 10, 2019 at 10:23:52PM +0100, Tomas Vondra wrote: >> > On Mon, Nov 11, 2019 at 10:08:58AM +1300, Thomas Munro wrote: >> > Can't we simply compute two hash values, using different seeds - one for >> > bucket and the other for batch? Of course, that'll be more expensive. >> >> Meh, I realized that's pretty much just a different way to get 64-bit >> hashes (which is what you mentioned). > >I'm not sure it's really the same, given practical realities in >postgres. Right now the "extended" hash function supporting 64 bit hash >functions is optional. So we couldn't unconditionally rely on it being >present, even in master, unless we're prepared to declare it as >required from now on. > >So computing two different hash values at the same time, by using a >different IV and a different combine function, doesn't seem like an >unreasonable approach. > True. I was commenting on the theoretical fact that computing two 32-bit hashes is close to computing a 64-bit hash, but you're right there are implementation details that may make it more usable in our case. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Rotate instead of shifting hash join batch number.
- 5c0a132cf141 9.4.26 landed
- 893eaf0be8be 9.5.21 landed
- 15861deb65cd 9.6.17 landed
- 8e89bc6dfd3d 10.12 landed
- 9e551a14cb45 11.7 landed
- 8052aaf521e4 12.2 landed
- e69d64454778 13.0 landed