Re: Out of Memory errors are frustrating as heck!
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Justin Pryzby <pryzby@telsasoft.com>, Gunther <raj@gusw.net>,
pgsql-performance@lists.postgresql.org,
Alvaro Herrera <alvherre@2ndquadrant.com>
Date: 2019-04-21T14:36:43Z
Lists: pgsql-performance
Jeff Janes <jeff.janes@gmail.com> writes: > The growEnabled stuff only prevents infinite loops. It doesn't prevent > extreme silliness. > If a single 32 bit hash value has enough tuples by itself to not fit in > work_mem, then it will keep splitting until that value is in a batch by > itself before shutting off Right, that's the code's intention. If that's not good enough for this case, we'll need to understand the details a bit better before we can design a better(?) heuristic. I suspect, however, that we might be better off just taking the existence of the I/O buffers into account somehow while deciding whether it's worth growing further. That is, I'm imagining adding a second independent reason for shutting off growEnabled, along the lines of "increasing nbatch any further will require an unreasonable amount of buffer memory". The question then becomes how to define "unreasonable". regards, tom lane
Commits
-
Consider BufFiles when adjusting hashjoin parameters
- a1b4f289beec 18.0 landed
-
Allocate hash join files in a separate memory context
- 8c4040edf456 16.0 landed