2011/6/2 Robert Haas <robertmh...@gmail.com>: > On Wed, Jun 1, 2011 at 7:35 PM, Mark Kirkwood > <mark.kirkw...@catalyst.net.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
