On 5 April 2016 at 11:23, Fujii Masao <masao.fu...@gmail.com> wrote: > 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 ? >
Sure > > 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. > I think we would all agree an insertion sort would be the fastest for k ~ 2-5, no much discussion there. We do already use that in this section of code, namely SHMQueue. > > The syntax and doc changes would take a couple of > > hours. > > Yes, the updates of documentation would need more time. > I can help, if you wish that. "any k" is in my mind what people would be expecting us to deliver with this feature, which is why I suggest it now, especially since it is a small additional item. Please don't see these comments as blocking your progress to commit. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
