Re: PostgreSQL Performance on OpenBSD

From: Doug McNaught <doug(at)mcnaught(dot)org>
To: jim(at)nasby(dot)net
Cc: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Martin Foster <martin(at)ethereal-realms(dot)org>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: PostgreSQL Performance on OpenBSD
Date: 2003-05-21 19:37:32
Message-ID: m3of1w2irn.fsf@varsoon.wireboard.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Jim C. Nasby" <jim(at)nasby(dot)net> writes:

> On Mon, May 19, 2003 at 08:50:31PM -0400, Doug McNaught wrote:

> > Per-connection is easy: 'man ulimit'
> >
> > Across all connections is possible if your system supports per-user
> > limits (in addition to per-process) but otherwise all the bookkeeping
> > would have to be done in the server, kept in shared memory and managed
> > with a semaphore. Somehow I doubt you'd get that patch accepted. :)
>
> Where would you do the ulimit? In the pgsql ~/.profile?

In whatever script starts the postmaster.

> More importantly, what happens when this limit is hit? I'm guessing the
> engine would fail, which isn't very helpful. If the server tracked
> resource usage on it's own, it would be able to throttle back things
> like sort memory when things started getting tight.

That's a lot of overhead for a feature that's not needed for most
installations.

It's already not that hard to put a crude limit on memory usage: set
your shared buffers and sort_mem appropriately, taking into account
the number of connections expected and the memory in the system. I
fail to see how more detailed resource accounting would be a win,
given that the application doesn't know what other apps are on the
system and how close it is to the swap limit at any given time.

-Doug

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Richard Gration 2003-05-21 19:47:49 Unique index hassles
Previous Message Bruno Wolff III 2003-05-21 19:32:46 Re: SELECT DISTINCT ON bug?