| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | 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>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Using quicksort for every external sort run |
| Date: | 2015-11-20 01:32:41 |
| Message-ID: | CAM-w4HMVPgqv4b251asVtjhnT7Csb3LQAJKcVgGxz9v3Xt1h_Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 20, 2015 at 12:54 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> * One run can be created with replacement selection, where a
> hyrbid-sort merge strategy needs to create and then merge many runs.
> When I started work on this patch, I was pretty sure that case would
> be noticeably regressed. I was wrong.
Hm. Have you tested a nearly-sorted input set around 1.5x the size of
work_mem? That should produce a single run using the heap to generate
runs but generate two runs if, AIUI, you're just filling work_mem,
running quicksort, dumping that run entirely and starting fresh.
I don't mean to say it's representative but if you're looking for a
worst case...
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-11-20 01:42:16 | Re: Typo in file header comment of replorigindesc.c |
| Previous Message | Amit Langote | 2015-11-20 01:29:52 | Re: [PROPOSAL] VACUUM Progress Checker. |