On Sat, Jun 13, 2015 at 6:24 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> I think we should really address this. Attached patch adds a new
>> release note item for it. It also adds to the documentation that
>> explains why users should prefer varchar(n)/text to character(n); the
>> lack of abbreviated key support now becomes a huge disadvantage for
>> character(n), whereas in previous versions the disadvantages were
>> fairly minor.
>>
>> In passing, I updated the existing sort item to reflect that only
>> varchar(n), text, and numeric benefit from the abbreviation
>> optimization (not character types more generally + numeric), and added
>> a note on the effectiveness of the abbreviation optimization alone.
>
> This all also seems like overkill to me. Users just don't care about
> this level of detail, and are easily confused by it.
Really? The pre-check thing wasn't too complex for Magnus to have a
couple of bullet points on it *specifically* in his high level NYC
talk on Postgres 9.5 features [1]. I don't think it's hard to
understand at all.
Also, it's simply incorrect to describe abbreviation as: "Improve the
speed of sorting character and numeric fields". Character fields
presumably include character(n), and as I pointed out character(n)
lacks abbreviation support. That needs to be documented as an
additional disadvantage of character(n) vs text/varchar(n) in the
documentation where the trade-off is already discussed (i.e. not in
the release notes), because it makes a *huge* difference. And ISTM
that it should also be clear from the release notes themselves. We
seemingly always have <type> </type> tags when types are named in
release notes.
[1] http://www.hagander.net/talks/postgresql95.pdf
--
Peter Geoghegan
