Re: Inlining comparators as a performance optimisation
От | Simon Riggs |
---|---|
Тема | Re: Inlining comparators as a performance optimisation |
Дата | |
Msg-id | CA+U5nM+uZu13isg5om_Comz3=m+xfLQh9aZkghvADRpRLniprg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inlining comparators as a performance optimisation (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Nov 18, 2011 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> On Fri, Nov 18, 2011 at 5:20 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> I think that we should really consider doing with this patch what Tom >>> suggested upthread; namely, looking for a mechanism to allow >>> individual datatypes to offer up a comparator function that doesn't >>> require bouncing through FunctionCall2Coll(). > >> I don't think its credible to implement that kind of generic >> improvement at this stage of the release cycle. > > Er, *what*? We're in mid development cycle, we are nowhere near > release. When exactly would you have us make major changes? > > In any case, what I understood Robert to be proposing was an add-on > feature that could be implemented in one datatype at a time. Not > a global flag day. We couldn't really do the latter anyway without > making life very unpleasant for authors of extension datatypes. Tom, whenever you think I've said something you really disagree with, just assume there's a misunderstanding. Like here. Of course it is OK to make such changes at this time. Given we have <2 months to the last CF of this release, inventing a generic infrastructure is unlikely to be finished and complete in this dev cycle, so requesting that isn't a practical suggestion, IMHO. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: