Re: One process per session lack of sharing

2016-07-15 13:25 GMT+02:00 <AMatveev(at)bitec(dot)ru>:

> Hi
>
>
> > 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.
>
>