Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement
От | Michael Banck |
---|---|
Тема | Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement |
Дата | |
Msg-id | 1491728411.25270.51.camel@credativ.de обсуждение исходный текст |
Ответ на | Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement (Josh Berkus <josh@berkus.org>) |
Ответы |
Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement
|
Список | pgsql-advocacy |
Am Samstag, den 08.04.2017, 13:26 -0700 schrieb Josh Berkus: > On 04/08/2017 12:53 PM, Justin Clift wrote: > > On 8 Apr 2017, at 20:48, Josh Berkus <josh@berkus.org> wrote: > > <snip> > >> From a PR standpoint, 5 is the absolute max, and 3 is better. Really, > >> the ideal situation is a set of features which can be closely tied > >> together around a simple theme. > > > > * Replication > > * Performance > > * Reliability > > Well, if we take logical replication, quorum commit, connection failover > and partitioning, that together is a serious scale-out story. I'm cautious about how to tie logical replication, partitioning and connection failover into the (same) scale-out story. Also, 9.6 had remote_apply, which is arguably at least as important as quorum commit, as it means querying the standby right afterwards will result in the expected behavior; if we just had quorum_commit with synchronous_commit merely to 'on', querying the sync standbys immediately after a commit might still return the old rows (the new rows are written to WAL so are crash-safe, but are not necessarily replayed yet), to the best of my knowledge. So quorum commit extends remote_apply to multiple standbys. Finally, note that even though libpq now can handle mutiple hosts in the connection string, it won't load-balance between those (in contrast to pgJDBC BTW, which can do load balancing), but just use the next one if the current connection goes away (i.e. failover). Load-Balancing still needs external tooling for now. So we need to be rather careful about not over-selling things here, IMO (while not under-selling either, of course). Others more familiar with the new feature will hopefully weigh in. Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.banck@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
В списке pgsql-advocacy по дате отправления: