On Sat, Aug 2, 2014 at 1:15 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > Great, I'll wait for the patch.
I'll post something over the weekend. > Do you mean: > > a) you don't understand what the patch should look like? or > b) you don't understand why it's been requested? > > If a), I admit I don't remember the details of this patch or patches very > well either, but looking back at the archives here: > http://www.postgresql.org/message-id/CAM3SWZQVnuomFBWNHOyRQ8t+nVJp+3=e58jvvx_a9y04qmh...@mail.gmail.com, > I think you had a pretty solid idea of how the split should look like. So, > please do that, i.e. post the patch that Robert did 2 years ago that gave > the 7% speedup, rebased over master. I don't recall the details of that > patch, so please explain briefly what it does, as if it was submitted for > the first time. Robert's 2012 patch just elides the fmgr overhead, like any sort support routine, so you just go through a function pointer and not a function pointer to a shim function with a fmgr call. It ends up having the sort support routine do a dew things once that might otherwise have to take place once per comparison. It's more or less a basic sort support routine, and nothing more. My question is: What is the reason for splitting the patch? Is it that you or Robert don't agree with my assessment of the 2012 patch, and you think there might be some subtlety to it that I'm not aware of? Do you just want to do this incrementally because it's easier to digest that way? This is a pertinent question. You said something about understanding where the benefits come from here, which is fair, but my point was that I actually do understand that the benefits clearly mostly come from the new abbreviated key idea. As the author of the 2012 patch, I imagine that Robert must be pretty confident that's the case too, but I don't want to presume that. As I said, I don't have a problem with breaking out the patch. I am not trying to artificially link the two. It just isn't obvious to me that you're aware that most of the benefit, and indeed all of the potential for regressions clearly comes from this abbreviated key idea. So sure, we can break out the patch and commit the first part fairly easily, almost entirely on the basis of 2012 discussion. What you may have missed here is that the 2012 patch wasn't committed for reasons entirely unrelated to the merit of the idea. If we were to commit essentially the same 2012 patch, that is a very straightforward matter, and is only a small fraction of our work here. The 2012 patch really should have been committed in 2012. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers