From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Christian Schröder <cs(at)deriva(dot)de> |
Cc: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Performance of subselects |
Date: | 2009-03-09 11:24:25 |
Message-ID: | dcc563d10903090424jee2c345k7f3bb11f2931b5f5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2009/3/9 Christian Schröder <cs(at)deriva(dot)de>:
> Scott Marlowe wrote:
>>>
>>> you can run out of memory if too many connections try to use too much
>>> of it at the same time, that's why it is advisable to set work_mem per
>>> connection/query, should the connection/query require more.
>>>
>>
>> Definitely.
>>
>
> I understand why this is advisable; however, something inside me hates the
> idea to put this kind of database specific stuff inside an application. How
> about portability? Why does the application developer have to know about
> database internals? He knows sql, that should be sufficient.
> I have the (maybe naive) idea of a clear separation of database
> administration (including performance tuning) and application development.
> Is this idea completely wrong?
You can always use a different account for things that need big
work_mem (typically reporting queries etc.) and alter that user to
have a different work_mem. That all the dev needs to know is which
account to use. You can also set it by database if that's a better
fit.
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2009-03-09 11:49:43 | Re: Performance of subselects |
Previous Message | Grzegorz Jaśkiewicz | 2009-03-09 11:14:57 | Re: commit/rollback in postgre 8.2 |