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

2011/6/2 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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?

you're sorting limits for 'executor' and limits for 'planner': uses
too much CPU time VS has too high an estimated cost.

(backend)_work_(disk|mem) looks good also for the 'has too high an
estimated cost' series: limiter at the planner level should allow
planner to change its strategy, I think... But probably not something
to consider too much right now.

>
> 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.

I am not specially attached to a name, idea was not to use work_disk
but backend_work_disk. I agree with you anyway, and suggestion from
Tom is fine for me (temp_file_limit).

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

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support