I'd like to discuss scaleout at PGCon - Mailing list pgsql-hackers
From | MauMau |
---|---|
Subject | I'd like to discuss scaleout at PGCon |
Date | |
Msg-id | CC24DD872A854C668D506F47514506DC@tunaPC Whole thread Raw |
Responses |
Re: I'd like to discuss scaleout at PGCon
|
List | pgsql-hackers |
Hello, I'm going to attend PGCon in Ottawa for the first time. I am happy if I can meet you. Because I'm visually impaired, I only have vision to sense light. If you see a Japanese man with a height of 171 cm with a white cane, it's probably me. I'd be happy if you talk to me. But as I'm still far from good at listening and speaking English, I'm sorry if I take an unfriendly attitude or if I can not keep on talking for a long time. I'd like to have a session on scaleout design at the unconference. I've created a wiki page for that (this is still just a memo; I'd like to populate this page with you as the discussion in the community progresses). I'd appreciate it if someone could stand with me and facilitate the discussion at the unconference. https://wiki.postgresql.org/wiki/Scaleout_Design The background is ... our company is faced with an immediate need to develop the read-write scaleout feature on PostgreSQL. We tried Postgres-XL with much hope, but we found it difficult to achieve our performance goal. I will tell you the details at the conference. But personally, Postgres-XL seems to be very nice software, and I feel that good parts of it should be integrated into core. I know that many great hackers from 2ndQuadrant, EnterpriseDB, NTT, Postgres Professional, CitusData, and so on are addressing this difficult scaleout feature. I don't think yet we are competent to lead this development. On the other hand, we have a proprietary RDBMS called Symfoware (I'm sure you don't know it), which is not based on PostgreSQL, that provides the scaleout feature. Its architecture is a mix of shared nothing and shared everything. It implements deadlock detection and resolution without a central node or periodic monitoring, parallel 2PC across nodes, parallel crash recovery, client connection routing and failover without any overhead of intermediary middleware during SQL execution, etc. So we may be able to help in some way. I'd be happy if we could help the community to proceed with development of scaleout. If you have a session for scaleout outside the unconference, could you call me and let me join it? By the way, the popularity score of PostgreSQL finally exceeded 400 points in the DB-Engines ranking! The popularity difference with the top products has shrunk greatly. Let's make PostgreSQL more popular. https://db-engines.com/en/ranking [as of May 27, 2018] Oracle=1290.42 MySQL=1223.34 SQL Server=1085.84 PostgreSQL=400.90 MongoDB=342.11 (Oracle / PostgreSQL ratio is 3.2) [as of Feb 2016, according to a memo at hand] Oracle=1476.14 MySQL=1321.13 SQL Server=?? MongoDB=?? PostgreSQL=288.66 (Oracle / PostgreSQL ratio is 5.1) Regards MauMau
pgsql-hackers by date: