Re: Hope for a new PostgreSQL era?

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Hope for a new PostgreSQL era?
Дата
Msg-id 4EE17CE6.7020009@ringerc.id.au
обсуждение исходный текст
Ответ на Re: Hope for a new PostgreSQL era?  ("Tomas Vondra" <tv@fuzzy.cz>)
Список 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

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re:
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Function Question