Re: Hope for a new PostgreSQL era?

Le Thu, 8 Dec 2011 10:56:39 -0600,
Merlin Moncure <mmoncure@gmail.com> a écrit :

> On Thu, Dec 8, 2011 at 10:11 AM, Marc Cousin <cousinmarc@gmail.com>
> wrote:
> > Le Thu, 8 Dec 2011 09:29:28 -0600,
> > Merlin Moncure <mmoncure@gmail.com> a écrit :
> >
> >> On Thu, Dec 8, 2011 at 9:11 AM, Marc Cousin <cousinmarc@gmail.com>
> >> wrote:
> >> > Le Thu, 8 Dec 2011 12:27:22 +0000,
> >> > Simon Riggs <simon@2ndQuadrant.com> a écrit :
> >> >
> >> >> On Thu, Dec 8, 2011 at 11:24 AM, Craig Ringer
> >> >> <ringerc@ringerc.id.au> 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.