Re: Last Commitfest patches waiting review
От | Heikki Linnakangas |
---|---|
Тема | Re: Last Commitfest patches waiting review |
Дата | |
Msg-id | 5436E748.9010401@vmware.com обсуждение исходный текст |
Ответ на | Re: Last Commitfest patches waiting review (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Last Commitfest patches waiting review
|
Список | pgsql-hackers |
On 10/09/2014 10:25 PM, Peter Geoghegan wrote: > On Thu, Oct 9, 2014 at 12:14 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> B-tree index build uses tuplesort.c. What's missing? > > I don't think that all that much is missing. Tuplesort expects to work > with an index scankey when sorting B-Tree tuples. There needs to be > something like a reverse lookup of the sortsupport function. It looks > like a historical oversight, that would take time to fix, but wouldn't > be particularly challenging. You'd need to pick out the operators from > the scankey, so you'd have something like what tuplesort_begin_heap() > starts off with with tuplesort_begin_index_btree(). Oh, I didn't realize we don't do that already! I'm surprised, I would've expected index build to have been the first thing we'd use the SortSupport stuff in. Yeah, that seems worth doing, independently of the this patch. Can you write a separate patch to use SortSupport for B-tree index builds, please? Eliminating the FunctionCallInfoData overhead should shave off some some cycles from every index build. - Heikki
В списке pgsql-hackers по дате отправления: