> 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.
The most of our customers now use oracle enterprise edition. You can know better how important this is.
But I agree with you that in other cases we can use PostgreSql. We can use postgreSql with some disadvantages of pgBouncer anywhare where the scalability is not main risk.(Such customers usually don't buy Enterprise) >I don't believe so is cheaper to modify Postgres to > support threads than modify some Oracle applications.
The key is Scaling. Some parallels processing just can not be divorced from data without reducing performance. It very difficult question would be it possible at all to get comparable performance at application server for such cases. If we "inject" applications server to postgreSql for that scalability and functionality we need multithreading.
but parallel processing doesn't requires threading support - see PostgreSQL 9.6 features.
I am not sure, but I am thinking so PL/SQL is based on processed and not on threads too. So maybe this discussion is little bit out, because we use different terms.
Regards
Pavel
If customization for every project is not big. It's may be tuned. But from some point the tuning is not profitable. (The database works in 24x7 and we need the ability to fix bugs on the fly) So If for some reason we would start to use postgresql. There is always a question what to choose funcionality or scalability. And usually our customers need both. >I don't believe so is cheaper For us it's may be not cheaper. It's just imposible.
