Le Thu, 8 Dec 2011 10:56:39 -0600, Merlin Moncure <mmoncure@xxxxxxxxx> a écrit : > 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. For us who can change our application code, of course. But some people can't. > > 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. Sure. I'm not advocating this. Neither am I advocating using Oracle by the way. I'm just as pro-postgresql as anyone else. I just wanted to weigh the pros and cons of Oracle's way of doing things versus pgbouncer. And the shared server approach has its merits. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
