| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, daveg <daveg(at)sonic(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Limit allocated memory per session |
| Date: | 2009-10-01 16:37:05 |
| Message-ID: | 20754.1254415025@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Euler Taveira de Oliveira <euler(at)timbira(dot)com> writes:
> I see. Tough problem is: how do we get per backend memory usage accurately? Is
> it relying on OS specific API the only way?
Given all the third-party libraries (perl, python, libxml2, yadda yadda)
that can be in use and won't go through palloc, I think that this would
have to be done at the OS level to be very meaningful.
The other problem is the one Robert touched on: what you actually *want*
is something entirely different, namely for the backend to actively try
to meet an overall target for its memory usage, rather than having
queries fail ungracefully when they hit an arbitrary limit that the
planner didn't even know about.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-10-01 16:42:15 | Re: FSM search modes |
| Previous Message | Kevin Grittner | 2009-10-01 16:32:08 | Re: FSM search modes |