Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash
James Coleman <jtc331@gmail.com>
From: James Coleman <jtc331@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-11-10T02:25:46Z
Lists: pgsql-bugs
On Sat, Nov 9, 2019 at 6:14 PM Thomas Munro <thomas.munro@gmail.com> wrote: > > On Sun, Nov 10, 2019 at 7:27 AM Tomas Vondra > <tomas.vondra@2ndquadrant.com> wrote: > > Hmmm, but the expected row width is only 16B, and with 6M rows that's > > only about 90GB. So how come this needs 1TB temporary files? I'm sure > > there's a bit of overhead, but 10X seems a bit much. > > (s/6M/6B/) Yeah, that comes out to only ~90GB but ... PHJ doesn't > immediately unlink files from the previous generation when it > repartitions. You need at two generations' worth of files (old and > new) while repartitioning, but you don't need the grand-parent > generation. I didn't think this was a problem because I didn't expect > to have to repartition many times (and there is a similar but > different kind of amplification in the non-parallel code). If this > problem is due to the 100% extreme skew threshold causing us to go > berserk, then that 10X multiplier is of the right order, if you > imagine this thing started out with ~512 batches and got up to ~1M > batches before it blew a gasket. Are you saying that it also doesn't unlink the grand-parent until the end?
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