On Thu, Dec 8, 2011 at 10:11 AM, Marc Cousin <cousinmarc@xxxxxxxxx> wrote: > Le Thu, 8 Dec 2011 09:29:28 -0600, > Merlin Moncure <mmoncure@xxxxxxxxx> a écrit : > >> On Thu, Dec 8, 2011 at 9:11 AM, Marc Cousin <cousinmarc@xxxxxxxxx> >> wrote: >> > Le Thu, 8 Dec 2011 12:27:22 +0000, >> > Simon Riggs <simon@xxxxxxxxxxxxxxx> a écrit : >> > >> >> On Thu, Dec 8, 2011 at 11:24 AM, Craig Ringer >> >> <ringerc@xxxxxxxxxxxxx> wrote: >> >> >> >> > Areas in which Pg seems significantly less capable include: >> >> >> >> Please can you explain the features Oracle has in these area, I'm >> >> not clear. Thanks. >> > >> > Maybe I can answer from my own Oracle experience. I hope it will be >> > what Craig had in mind :) >> > >> >> >> >> >> >> > - 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. >> >> you have a couple of very good options to achieve the same in postgres >> -- pgbouncer, pgpool. >> > > I wish it was the same (I use and like both pgbouncer and pgpool too, > and they do a good job, I'm not arguing on that). But unfortunately it > isn't: you still have the notion of session for each connected client > in Oracle when using the shared servers model. > > It means you keep your session variables, your prepared statements, > your running transaction, etc… in each individual session while having > the multiplexing equivalent of a 'statement level' from pgbouncer. yeah -- maybe we could use a server side feature that could allow you to save a session state and load it up later to make life easier for connection pooled applications. however, it's not really that much work to organize most of the things you'd use for this in an application managed session instead of database managed one. regarding the "enterprises won't use community supplied postgresql add ons" point, this completely true in many cases. I do think pgbouncer should be seriously considered for advancement as a core feature. That said, this should be done on its own merits, not to satisfy the capricious whims of enterprises. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
