Re: Restricting Postgres - Mailing list pgsql-performance

From Martin Foster
Subject Re: Restricting Postgres
Date
Msg-id 418A2BE2.70609@ethereal-realms.org
Whole thread Raw
In response to Re: Restricting Postgres  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-performance
Simon Riggs wrote
>
>
> All workloads are not created equally, so mixing them can be tricky.
> This will be better in 8.0 because seq scans don't spoil the cache.
>
> Apache is effectively able to segregate the workloads because each
> workload is "in a directory". SQL isn't stored anywhere for PostgreSQL
> to say "just those ones please", so defining which statements are in
> which workload is the tricky part.
>
> PostgreSQL workload management could look at userid, tables, processor
> load (?) and estimated cost to decide what to do.
>
> There is a TODO item on limiting numbers of connections per
> userid/group, in addition to the max number of sessions per server.
>
> Perhaps the easiest way would be to have the Apache workloads segregated
> by PostgreSQL userid, then limit connections to each.
>

Apache has a global setting for load average limits, the above was just
a module which extended the capability.  It might also make sense to
have limitations set on schema's which can be used in a similar way to
Apache directories.

While for most people the database protecting itself against a sudden
surge of high traffic would be undesirable.   It can help those who run
dynamically driven sites and get slammed by Slashdot for example.

    Martin Foster
    Creator/Designer Ethereal Realms
    martin@ethereal-realms.org



pgsql-performance by date:

Previous
From: Martin Foster
Date:
Subject: Re: Restricting Postgres
Next
From: Andrew Sullivan
Date:
Subject: Re: preloading indexes