On Thu, Apr 3, 2014 at 3:19 PM, Thom Brown <t...@linux.com> wrote: > Master: 38.450082 / 37.440701 (avg: 37.9453915) > Patch: 153.321946 / 145.004726 (avg: 149.163336)
I think that those are objectively very large reductions in a cost that figures prominently in most workloads. Based solely on those facts, but also on the fairly low complexity of the patch, it may be worth considering committing this before 9.4 goes into feature freeze, purely as something that just adds a SortSupport function for the default text opclass, with more or less the same cases accelerated as with the existing SortSupport-supplying-opclasses. There has been only very modest expansions to the SortSupport and tuplesort code. I haven't generalized this to work with other areas where a normalized key could be put to good use, but I see no reason to block on that. Obviously I've missed the final commitfest deadline by a wide berth. I don't suggest this lightly, and it in no small part has a lot to do with the patch being simple and easy to reason about. The patch could almost (but not quite) be written as part of a third party text operator class's sort support routine. I think that if an individual committer were willing to commit this at their own discretion before feature freeze, outside of the formal commitfest process, that would not be an unreasonable thing in these particular, somewhat unusual circumstances. I defer entirely to the judgement of others here - this is not an issue that I feel justified in expressing a strong opinion on, and in fact I don't have such an opinion anyway. However, by actually looking at the risks and the benefits here, I think everyone will at least understand why I'd feel justified in broaching the topic. This is a very simple idea, and a rather old one at that. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
