Re: Assembling "top features" list for beta announcement

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 <[email protected]> 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: [email protected]

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



-- 
Sent via pgsql-advocacy mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy