| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(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>, Greg S <stark(at)mit(dot)edu> |
| Subject: | Re: Using quicksort for every external sort run |
| Date: | 2016-01-29 17:24:21 |
| Message-ID: | CA+TgmoaPhB_c7+QxvsUZg6zwxODY2muBA3uDwaF-SLzf-qgWbA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 27, 2016 at 8:20 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Correct me if I'm wrong, but I think that the only outstanding issue
> with all patches posted here so far is the "quicksort with spillover"
> cost model. Hopefully this can be cleared up soon. As I've said, I am
> very receptive to other people's suggestions about how that should
> work.
I feel like this could be data driven. I mean, the cost model is
based mainly on the tuple width and the size of the SortTuple array.
So, it should be possible to tests of both algorithms on 32, 64, 96,
128, ... byte tuples with a SortTuple array that is 256MB, 512MB,
768MB, 1GB, ... Then we can judge how closely the cost model comes to
mimicking the actual behavior.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thom Brown | 2016-01-29 17:43:02 | Re: [WIP] Effective storage of duplicates in B-tree index. |
| Previous Message | Catalin Iacob | 2016-01-29 17:09:19 | Re: proposal: PL/Pythonu - function ereport |