Re: One process per session lack of sharing

Hi

> It's mostly working, but there are workloads where it
> fails badly - and competing database products survive a number of
> scenarios where we just fall on our face.

> So, I actually think it would be a good idea to think about this.

Just to think.

http://www.tiobe.com/tiobe_index

The pl/sql has 18-th position.
Where is pgSql.

I've looked up the Ide for pgSql. If compare with oracle I can say
there is not tools which can compete with "PlSql developer" for
example. (functinality / price)
https://www.allroundautomations.com/plsqldev.html?gclid=CjwKEAjw8Jy8BRCE0pOC9qzRhkMSJABC1pvJepfRpWeyMJ7CTZzlQE_PojlBO0vqGIZvVSW4jiQxShoC4PLw_wcB
Why?
May it because choosing another database is more profitable?

I can't say for others, but for us:
Offcourse We can implement some of our task in postgreSql.
But when I think on full migration, it's just not real.
We can contribute something but we can't work against postgreSql architecture.
Our calculation shows that it is cheaper to implement "Session per
thread" themselfs for example. But it's more cheaper to buy Oracle(Even if we
would write from scratch).
And there is just no customers which want to pay for that.
Note, we don't have enough skill at postgreSql and the think that postgresql core team may do for a month, we can do for years.
So in our layer we just can't attract resource for that task.

At other side there is people who have infrastructure, skills and experience but they
fill comfortable as is ""

> there's not that much motivation to do a ton of work inside the database
> to solve it there.
It's clear, they work on there task. We all work on our task.
But it's just a wall.
It's sad.

There is proverbial in russia: "It's shine and poverty of open source"

May be it is this case :)