From: | AMatveev(at)bitec(dot)ru |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: One process per session lack of sharing |
Date: | 2016-07-15 11:25:20 |
Message-ID: | 767937182.20160715142520@bitec.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2016-07-15 11:46:59 | Re: Documentation fix for CREATE FUNCTION |
Previous Message | Craig Ringer | 2016-07-15 11:03:11 | Re: One process per session lack of sharing |