From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP - Add ability to constrain backend temporary file space |
Date: | 2011-02-18 21:38:27 |
Message-ID: | 4D5EE6D3.9010803@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Obviously you need to do the same sort of arithmetic as you do with
> work_mem to decide on a reasonable limit to cope with multiple users
> creating temp files. Conservative dbas might want to set it to (free
> disk)/max_connections etc. Obviously for ad-hoc systems it is a bit more
> challenging - but having a per-backend limit is way better than having
> what we have now, which is ... errr... nothing.
Agreed.
> To answer the other question, what happens when the limit is exceeded is
> modeled on statement timeout, i.e query is canceled and a message says
> why (exceeded temp files size).
When does this happen? When you try to allocate the file, or when it
does the original tape sort estimate?
The disadvantage of the former is that the user waited for minutes in
order to have their query cancelled. The disadvantage of the latter is
that the estimate isn't remotely accurate.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-18 21:41:23 | Re: WIP - Add ability to constrain backend temporary file space |
Previous Message | Mark Kirkwood | 2011-02-18 21:33:48 | Re: WIP - Add ability to constrain backend temporary file space |