Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, James Coleman <jtc331@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-11-10T22:46:31Z
Lists: pgsql-bugs
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. Greetings, Andres Freund
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