Re: Hope for a new PostgreSQL era?

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: Marc Cousin <cousinmarc(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Hope for a new PostgreSQL era?
Date: 2011-12-09 03:13:42
Message-ID: 4EE17CE6.7020009@ringerc.id.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 12/09/2011 01:02 AM, Tomas Vondra wrote:
> 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.
>
Yep - a connection pool that could save and restore session state,
separating "executor/backend" from "connection/session", would produce
much the same result with a lot less complexity. It's one of the reasons
I'd love to see in-core pooling, because I don't see how an out-of-core
solution can maintain session state like advisory locks, HOLD cursors, etc.

--
Craig Ringer

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2011-12-09 03:16:23 Re: Function Question
Previous Message Tom Lane 2011-12-09 03:13:06 Re: