Re: A worst case for qsort - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: A worst case for qsort
Date
Msg-id CAM3SWZR2R-ypWzJ=YpdKPKmchFe4xxgFmCYqPi86L=D9D0=x2g@mail.gmail.com
Whole thread Raw
In response to Re: A worst case for qsort  (Rod Taylor <rod.taylor@gmail.com>)
Responses Re: A worst case for qsort
List pgsql-hackers
On Thu, Aug 7, 2014 at 2:34 PM, Rod Taylor <rod.taylor@gmail.com> wrote:
> This one is frequently sorted as batch operations against the files are
> performed in alphabetical order to reduce conflict issues that a random
> ordering may cause between jobs.

Sure. There are cases out there. But, again, I have a hard time
imagining why you'd expect those to be pre-sorted in practice, and
particularly why you'd feel justified in expecting that to sort much
faster than equivalent though slightly imperfectly correlated data.
Without that, the fmgr-elision aspect of sort support appears to offer
enough for us to still win on balance [1], assuming 9.4 is our basis
of comparison.

[1] http://www.postgresql.org/message-id/CAM3SWZQHjxiyrsqBs5w3u-vTJ_jT2hp8o02big5wYb4m9Lp1jg@mail.gmail.com
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: A worst case for qsort
Next
From: Jerry Sievers
Date:
Subject: Re: Append to a GUC parameter ?