On Tue, Apr 5, 2016 at 6:09 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 5 April 2016 at 08:58, Amit Langote <Langote_Amit_f8@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/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services