Re: Performance of subselects

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.

In response to

Browse pgsql-general by date

  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