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 по дате отправления: