| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash |
| Date: | 2019-11-10 22:46:31 |
| Message-ID: | 20191110224631.uxpfccnql6pxllv2@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-11-10 23:44:38 | Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash |
| Previous Message | Thomas Munro | 2019-11-10 22:07:01 | Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash |