Re: Treating work_mem as a shared resource (Was: Parallel Hash take II) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)
Date
Msg-id CAH2-WznNquzj3+Qod1DKsaGsP-Q_dLSA2MvNUWbFj9OqTyai0A@mail.gmail.com
Whole thread Raw
In response to Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Nov 17, 2017 at 3:23 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Hmm.  I wonder if you are correct that hashing is the special case.
> Hashing and sorting are of course the two main operations -- but
> there's materialize and anything else that uses a CTE, and maybe other
> stuff I'm not thinking about right now.  You might be right that hash
> is the one where it really matters, but it's probably worth a bit more
> reflection on where it matters most and for what reasons.

I'd rather be approximately correct than precisely wrong. I think that
the current work_mem model is precisely wrong. I'm conscious of the
fact that we are loathe to create new GUCs (I sometimes think that
we're a bit too averse to doing so), but maybe there is room for
adding a second work_mem-alike GUC.

For now, I admit that I am applying fuzzy criteria, and that I could
easily have missed an important subtlety. Creating hash_mem instead of
sort_mem is a direction that is entirely debatable, and should
actually be debated. OTOH, it seems like a real problem that we don't
allow hashing to take full advantage of available main memory, and
*some* interim solution seems preferable to what we have now.

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: default range partition and constraint exclusion
Next
From: Sophie Herold
Date:
Subject: to_typemod(type_name) information function