Re: Re: patch review : Add ability to constrain backend temporary file space

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: patch review : Add ability to constrain backend temporary file space
Date: 2011-06-02 13:46:46
Message-ID: BANLkTikw67ZfX2UL8H7UU5wbVEL+mhbuBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 1, 2011 at 7:35 PM, Mark Kirkwood
<mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> wrote:
> Done - 'work_disk' it is to match 'work_mem'.

I guess I'm bikeshedding here, but I'm not sure I really buy this
parallel. work_mem is primarily a query planner parameter; it says,
if you're going to need more memory than this, then you have to
execute the plan some other way. This new parameter is not a query
planner paramater AIUI - its job is to KILL things if they exceed the
limit. In that sense it's more like statement_timeout. I can imagine
us wanting more parameters like this too. Kill the query if it...

...takes too long (statement_timeout)
...uses too much temporary file space (the current patch)
...uses too much CPU time
...uses too much RAM
...generates too much disk I/O
...has too high an estimated cost
...others?

So I'm not sure work_disk is a great name. Actually, work_mem is
already not a great name even for what it is, but at any rate I think
this is something different.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-06-02 13:49:20 Re: BLOB support
Previous Message Merlin Moncure 2011-06-02 13:30:49 Re: PQdeleteTuple function in libpq