| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Subject: | Re: Using quicksort for every external sort run |
| Date: | 2015-12-15 03:22:33 |
| Message-ID: | CAM3SWZQByOp9A7Y1NntOc1YAmG+o1sav2r_RPPSnhZ0s991m0w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 14, 2015 at 6:58 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> I ran sorts with various parameters on my small NAS server.
...
> without the extra memory optimizations.
Thanks for taking the time to benchmark the patch!
While I think it's perfectly fair that you didn't apply the final
on-the-fly merge "memory pool" patch, I also think that it's quite
possible that the regression you see at the very low end would be
significantly ameliorated or even eliminated by applying that patch,
too. After all, Jeff Janes had a much harder time finding a
regression, probably because he benchmarked all patches together.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2015-12-15 03:33:05 | Re: Using quicksort for every external sort run |
| Previous Message | Tomas Vondra | 2015-12-15 03:07:59 | Re: Tsvector editing functions |