| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(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: | 2015-12-14 03:37:41 |
| Message-ID: | CAM3SWZTOiJz6ZfwMxi_z=W94XnVkYiFsv4dGE1p7sr5waCnQbg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Dec 13, 2015 at 7:31 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> The reason for memtuples is to handle random access. Since we are no
> longer doing random access, we no longer need it.
>
> We could free memtuples, re-allocate just enough to form the binary
> heap for the N-way merge, and use all the rest of that space (which
> could be a significant fraction of work_mem) as part of the new pool.
Oh, you're talking about having the final on-the-fly merge use a
tuplestore-style array of pointers to "tuple proper" memory (this was
how tuplesort.c worked in all cases about 15 years ago, actually).
I thought about that. It's not obvious how we'd do without
SortTuple.tupindex during the merge phase, since it sometimes
represents an offset into memtuples (the SortTuple array). See "free
list" management within mergeonerun().
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2015-12-14 03:46:39 | Re: Disabling an index temporarily |
| Previous Message | Michael Paquier | 2015-12-14 03:36:01 | Re: Disabling an index temporarily |