On Sun, Nov 29, 2015 at 4:02 PM, Peter Geoghegan <p...@heroku.com> wrote: > The C collation is treated exactly the same as other collations when > considering whether the generation of abbreviated keys for text should > continue. This doesn't make much sense. With text, the big cost that > we are concerned about going to waste should abbreviated keys not > capture sufficient entropy is the cost of n strxfrm() calls. However, > the C collation doesn't use strxfrm() -- it uses memcmp(), which is > far cheaper. > > With other types, like numeric and now UUID, the cost of generating an > abbreviated key is significantly lower than text when using collations > other than the C collation. Their cost models reflect this, and abort > abbreviation far less aggressively than text's, even though the > trade-off is very similar when text uses the C collation. > > Attached patch fixes this inconsistency by making it significantly > less likely that abbreviation will be aborted when the C collation is > in use. The behavior with other collations is unchanged. This should > be backpatched to 9.5 as a bugfix, IMV.
Could you provide a test case where this change is a winner for the C locale but a loser for some other locale? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers