On 8 Prosinec 2011, 16:11, Marc Cousin wrote: >> > - admission control, queuing and resource limiting to optimally >> > load a machine. Some limited level is possible with external >> > pooling, but only by limiting concurrent workers. > > Oracle has natively two ways of handling inbound connections: > - Dedicated, which is very similar to the PostgreSQL way of accepting > connections: accept(), fork() and so on > - Shared, which is based on processes listening and handling the > connections (called dispatchers) and processes doing the real work > (called workers, obviously). All of this works internally with > some sort of queuing and storing results in shared memory (I don't > remember the details of it) > > The advantage of this second architecture being of course that you > can't have more than N workers hitting your database simultaneously. So > it's easier to keep the load on the server to a reasonable value. Which is exactly what pgbouncer and other connection pools are for ... >> > - prioritisation of queries or users. It's hard to say "prefer this >> > query over this one, give it more resources" or "user A's work >> > always preempts user B's" in Pg. >> > It's called the resource manager in Oracle. You define 'resource plans', > 'consumer groups', etc… and you get some sort of QoS for your queries. > It's mostly about CPU resource allocation if I remember correctly (I > never used it, except during training :) ) And it's damn difficult to get it working properly ... the simpler the better here. Tomas -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
