2016-07-15 13:25 GMT+02:00 <amatv...@bitec.ru>:
> > 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
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
> 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.