Re: B-Tree support function number 3 (strxfrm() optimization)

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Date: 2014-09-16 00:18:39
Message-ID: CAM3SWZT=mxoz25f6YXxxCzyti4JX0C_FpdwH0FhTd3Y+qF2-Ng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 15, 2014 at 4:21 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> I attach a much simpler patch, that only adds an opportunistic
> "memcmp() == 0" before a possible strcoll(). Both
> bttextfastcmp_locale() and varstr_cmp() have the optimization added,
> since there is no point in leaving anyone out for this part.

FWIW, it occurs to me that this could be a big win for cases like
ExecMergeJoin(). Obviously, abbreviated keys will usually make your
merge join on text attributes a lot faster in the common case where a
sort is involved (if we consider that the sort is integral to the cost
of the join). However, when making sure that inner and outer tuples
match, the MJCompare() call will *very* frequently get away with a
cheap memcmp(). That could make a very significant additional
difference, I think.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Silva 2014-09-16 01:27:07 Re: jsonb format is pessimal for toast compression
Previous Message Peter Geoghegan 2014-09-15 23:44:07 Re: jsonb format is pessimal for toast compression