Re: One process per session lack of sharing

Поиск
Список
Период
Сортировка
От AMatveev@bitec.ru
Тема Re: One process per session lack of sharing
Дата
Msg-id 1533411784.20160715132036@bitec.ru
обсуждение исходный текст
Ответ на Re: One process per session lack of sharing  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: One process per session lack of sharing  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Hi


> I disagree - there is lot of possible targets with much higher
> benefits - columns storage, effective execution - compiled
> execution, implementation of temporal databases, better support for
> dynamic structures, better support for XML, JSON, integration of connection pooling, ...
Off course  the  task is different so optimal configuration is different too.
So the best balance between process per thread can change.
But now he is in one extreme point.


> There is only few use cases - mostly related to Oracle emulation
It's few cases for one and it's most cases for others.
> when multi threading is necessary - and few can be solved better -
> PLpgSQL to C compilation and similar techniques.
It's few cases for one and it's most cases for others.
In our cases we just buy oracle and it's would be cheeper.
Off  course  if  our customers for some reason would agree to pay  for that
technique. We have nothing against.

> The organization of work is hard, but pretty harder is doing this
> work - and doing it without impact on current code base, current
> users. MySQL is thread based database - is better than Postgres, or
> there is more users migrated from Orace? Not.

We want to decide our task by PostgreSql as easy as by Oracle.
So you can say  You should buy oracle and You will be right.

I'm just interested if this is the position of the majority.




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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: One process per session lack of sharing
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: BUG #14245: Segfault on weird to_tsquery