From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | MauMau <maumau307(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: I'd like to discuss scaleout at PGCon |
Date: | 2018-06-06 08:44:07 |
Message-ID: | CANP8+j+UJsDTDp+r5RBvtH6BzU1wLZ4HJPhgFxySeEocATh_Ag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5 June 2018 at 17:14, MauMau <maumau307(at)gmail(dot)com> wrote:
> Furthermore, an extra hop and double parsing/planning could matter for
> analytic queries, too. For example, SAP HANA boasts of scanning 1
> billion rows in one second. In HANA's scaleout architecture, an
> application can connect to any worker node and the node communicates
> with other nodes only when necessary (there's one special node called
> "master", but it manages the catalog and transactions; it's not an
> extra hop like the coordinator in XL). Vertica is an MPP analytics
> database, but it doesn't have a node like the coordinator, either. To
> achieve maximum performance for real-time queries, the scaleout
> architecture should avoid an extra hop when possible.
Agreed. When possible.
When is it possible?
Two ways I know of are:
1. have pre-knowledge in the client of where data is located
(difficult to scale)
2. you must put data in all places the client can connect to (i.e. multimaster)
Perhaps there are more?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2018-06-06 08:58:51 | Re: I'd like to discuss scaleout at PGCon |
Previous Message | Amit Langote | 2018-06-06 08:08:14 | Re: Remove mention in docs that foreign keys on partitioned tables are not supported |