| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, 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: | 2016-01-30 07:29:14 |
| Message-ID: | CAM-w4HPtDTTQTfe7G+uD3gdeycsHwhKKJxgFiQwAw3tqQTyV7g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 30 Jan 2016 8:27 am, "Greg Stark" <stark(at)mit(dot)edu> wrote:
>
>
> On 29 Jan 2016 11:58 pm, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:
> > It
> > seems pretty easy to construct cases where this technique regresses,
> > and a large percentage of those cases are precisely those where
> > replacement selection would have produced a single run, avoiding the
> > merge step altogether.
>
> Now that avoiding the merge phase altogether didn't necessarily represent
any actual advantage.
>
> We don't find out we've avoided the merge phase until the entire run has
been spiked to disk.
Hm, sorry about the phone typos. I thought I proofread it as I went but
obviously not that effectively...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2016-01-30 07:58:56 | Re: [PATCH] Refactoring of LWLock tranches |
| Previous Message | Greg Stark | 2016-01-30 07:27:21 | Re: Using quicksort for every external sort run |