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@xxxxxxxxxx> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@xxxxxxxxx Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
