From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Konstantin Knizhnik' <k(dot)knizhnik(at)postgrespro(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: I'd like to discuss scaleout at PGCon |
Date: | 2018-06-07 06:24:12 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F9A048F@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> From: Konstantin Knizhnik [mailto:k(dot)knizhnik(at)postgrespro(dot)ru]
> I can not completely agree with it. I have done a lot of benchmarking of
> PostgreSQL, CitusDB, SparkSQL and native C/Scala code generated for
> TPC-H queries.
Wow, you have an amazingly abundant experience.
> I do not want to say that it is not possible to implement good analytic
> platform for OLAP on top of Postgres. But it is very challenged task.
> And IMHO choice of programming language is not so important. What is
> more important is format of storing data. The bast systems for data
> analytic: Vartica, HyPer, KDB,...
> are using vertical data mode. SparkSQL is also using Parquet file format
> which provides efficient extraction and processing of data.
> With abstract storage API Postgres is also given a chance to implement
> efficient storage for OLAP data processing. But huge amount of work has
> to be done here.
Agreed on huge amount of work... And I must admit my dream is a pipedream now.
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-06-07 06:43:13 | Fix obsolete comment |
Previous Message | Tsunakawa, Takayuki | 2018-06-07 06:17:21 | RE: I'd like to discuss scaleout at PGCon |