> 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.
Can be nice, if we can help to all Oracle users - but it is not possible in this world :( - there is lot of barriers - threading is only one, second should be different design of PL/SQL - it is based on out processed, next can be libraries, JAVA integration, and lot of others. I believe so lot of users can be simple migrated, NTT has statistics - 60% is migrated just with using Orafce. But still there will be 10% where migration is not possible without significant refactoring. I don't believe so is cheaper to modify Postgres to support threads than modify some Oracle applications.
The threading for Postgres is not small projects - it can require hundreds man days.
I'm just interested if this is the position of the majority.