Re: Hope for a new PostgreSQL era?

Le Thu, 8 Dec 2011 18:02:51 +0100,
"Tomas Vondra" <tv@fuzzy.cz> a écrit :

> On 8 Prosinec 2011, 17:11, Marc Cousin wrote:
> > Le Thu, 8 Dec 2011 09:29:28 -0600,
> >> >> > - 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.
>
> True, it is not exactly the same, it's similar. I don't think
> PostgreSQL will ever provide 'shared backends' the way Oracle does -
> it would require significant code change. Most of the benefits can be
> achieved by using a connection pool without the added complexity.

I didn't ask for it. It's just not the same, which was what I was
answering to.

>
> > 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.
>
> Yes. But if you expect that PostgreSQL will mimic Oracle architecture,
> then you're mistaken. It's simply a different solution with different
> architecture, and that means you may need to use different application
> design sometimes.

I just don't understand what you're getting all heated up for. I don't
want PostgreSQL to mimic Oracle, and I'm only answering to Simon's
question at the begining.

I'm just saying that there are differences between the pgbouncer approach
and the shared server approach, and benefits to the later (and to the
former too by the way, mainly simplicity so less bugs, as shared servers
architecture suffered from a lot of bugs).