Re: 9.5 release notes

On Thu, Jun 11, 2015 at 2:17 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Jun 11, 2015 at 4:23 PM, Peter Geoghegan <pg(at)heroku(dot)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