On Thu, Jun 11, 2015 at 2:17 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Jun 11, 2015 at 4:23 PM, Peter Geoghegan <p...@heroku.com> wrote: >> Secondly, Robert didn't credit himself as an author in his commit >> message for the abbreviated keys infrastructure + text opclass support >> *at all*. However, I think that Robert should be listed as a secondary >> author of the abbreviated keys infrastructure, and that he would agree >> that I am clearly the primary author. Andrew Gierth did work on the >> datum case for sortsupport + abbreviation, so I agree he should be >> listed as a secondary author of the infrastructure too, after Robert. > > I'd probably say Peter, Andrew, me.
If you bunch everything together, then yes, I'd agree. >> I think there should be a total of 4 items related to sorting. The >> wording I come up with may not be appropriate, but will give you an >> idea: >> >> * Allow sorting to be performed by inlined, non-SQL-callable >> comparison functions for CREATE INDEX, REINDEX and CLUSTER operations >> based on a B-Tree operator class. (5ea86e6e6 -- Geoghegan) >> >> * Add abbreviated key sorting infrastructure. This allows B-Tree >> operator classes to provide compact abbreviated representations of >> pass-by-reference types which are sorted with inexpensive comparisons. >> This makes sort operations with support for the infrastructure very >> significantly faster in the common case where most comparisons can be >> resolved with the abbreviated representation alone. (4ea51cdfe85 -- >> Geoghegan, Haas, Gierth, with Gierth's contribution coming from >> 78efd5c1 alone) >> >> * Add sortsupport (support for non-SQL callable interface for >> comparators) with abbreviation capability to text/varlena operator >> class. This significantly accelerates sorting on text columns. >> (4ea51cdfe85 too, but also b34e37bf. Worth noting separately IMV. >> Geoghegan, Haas). >> >> * Add sortsupport (support for non-SQL callable interface for >> comparators) with abbreviation capability to numeric operator class. >> This significantly accelerates sorting on numeric columns. (abd94bcac, >> Gierth) > > I think this is overkill. Bruce's single entry seems fine to me, > although we could adjust the wording a bit. We need this to be simple > enough that someone not immersed in the code can understand it, and as > soon as you talk about sortsupport as if it were a thing, you lose > that. I think that that is a valid point of view, but that we should get across that sortsupport works for all types with CREATE INDEX + CLUSTER now, including integers, for example. The reviewer of that particular piece of work, Andreas Karlsson, put it at a 10% - 15% improvement for CREATE INDEX on an integer column IIRC. That's not a bad little boost. -- 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
