Re: Why percent_rank is so slower than rank?

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm not sure whether or not to back-patch this into 9.0 and 8.4.
>> The code in tuplestore.c hasn't changed at all since 8.4, so
>> there's not much risk of cross-version bugs, but if I did miss
>> anything we could be shipping a buggy version next week.
>> Thoughts?

> Is there a performance regression involved, or is it a new feature
> which hasn't performed well on this type of query until your patch?

Well, since window functions didn't exist before 8.4, it's difficult to
argue that there was a regression. It's certainly a performance bug
though: nobody would expect that giving a query *more* work_mem would
cause it to run many times slower.

> If the latter, I'd be inclined to give it some time on HEAD and
> release it in the *following* minor release unless you're *very*
> confident it couldn't break anything.

Well, I'm reasonably confident in the patch, and it does pass regression
tests. But I've been wrong before.

I'm not terribly thrilled with that suggestion though. Do you have
reason to think that anybody is likely to exercise window functions in
HEAD, beyond what the regression tests do, in the next couple of months?
Slipping the application of the patch to back branches by a little bit
doesn't make a lot of management sense to me. I think either we trust
it and put it into back branches, or we don't trust it and put it only
in HEAD, so it goes through a beta cycle before hitting production.

regards, tom lane