On Mon, Mar 09, 2009 at 11:45:38AM +0100, Christian Schröder wrote:
> 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?
What about it? Portability among DBMS back-ends is an extremely
expensive and complicated proposition no matter how you approach it.
Unless your main value proposition is that portability--an
entity-relationship diagram extraction tool, for example--it's usually
not worth even attempting this.
> Why does the application developer have to know about database
> internals? He knows sql, that should be sufficient.
It's not.
> I have the (maybe naive) idea of a clear separation of database
> administration (including performance tuning) and application
> development. Is this idea completely wrong?
Yes. Fortunately, knowing this, you can adjust your expectations and
your development plan. :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
