From: | Marc Cousin <cousinmarc(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Hope for a new PostgreSQL era? |
Date: | 2011-12-08 16:11:32 |
Message-ID: | 20111208171132.69bd7181@marco-dalibo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Le Thu, 8 Dec 2011 09:29:28 -0600,
Merlin Moncure <mmoncure(at)gmail(dot)com> a écrit :
> On Thu, Dec 8, 2011 at 9:11 AM, Marc Cousin <cousinmarc(at)gmail(dot)com>
> wrote:
> > Le Thu, 8 Dec 2011 12:27:22 +0000,
> > Simon Riggs <simon(at)2ndQuadrant(dot)com> a écrit :
> >
> >> On Thu, Dec 8, 2011 at 11:24 AM, Craig Ringer
> >> <ringerc(at)ringerc(dot)id(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Brandl | 2011-12-08 16:18:42 | Statistics mismatch between n_live_tup and actual row count |
Previous Message | Andrew Sullivan | 2011-12-08 16:04:28 | Re: Hope for a new PostgreSQL era? |