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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: patch review : Add ability to constrain backend temporary file space
Дата
Msg-id BANLkTikw67ZfX2UL8H7UU5wbVEL+mhbuBQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch review : Add ability to constrain backend temporary file space  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Ответы Re: Re: patch review : Add ability to constrain backend temporary file space  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Re: patch review : Add ability to constrain backend temporary file space  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Список pgsql-hackers
On Wed, Jun 1, 2011 at 7:35 PM, Mark Kirkwood
<mark.kirkwood@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?

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: PQdeleteTuple function in libpq
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: BLOB support