On Tue, Apr 5, 2016 at 6:09 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 5 April 2016 at 08:58, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > >> >> >>>> So I am suggesting we put an extra keyword in front of the “k”, to >> > explain how the k responses should be gathered as an extension to the >> > the >> > syntax. I also think implementing “any k” is actually fairly trivial and >> > could be done for 9.6 (rather than just "first k"). >> >> +1 for 'first/any k (...)', with possibly only 'first' supported for now, >> if the 'any' case is more involved than we would like to spend time on, >> given the time considerations. IMHO, the extra keyword adds to clarity of >> the syntax. > > > Further thoughts: > > I said "any k" was faster, though what I mean is both faster and more > robust. If you have network peaks from any of the k sync standbys then the > user will wait longer. With "any k", if a network peak occurs, then another > standby response will work just as well. So the performance of "any k" will > be both faster, more consistent and less prone to misconfiguration. > > I also didn't explain why I think it is easy to implement "any k". > > All we need to do is change SyncRepGetOldestSyncRecPtr() so that it returns > the k'th oldest pointer of any named standby.
s/oldest/newest ? > Then use that to wake up user > backends. So the change requires only slightly modified logic in a very > isolated part of the code, almost all of which would be code inserts to cope > with the new option. Yes. Probably we need to use some time to find what algorithm is the best for searching the k'th newest pointer. > The syntax and doc changes would take a couple of > hours. Yes, the updates of documentation would need more time. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
