Re: Wrong Results from SP-GiST with Collations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Emre Hasegeli <emre(at)hasegeli(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Wrong Results from SP-GiST with Collations
Date: 2018-04-16 19:55:52
Message-ID: 26053.1523908552@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Mon, Apr 16, 2018 at 12:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> True. This way saves a few cycles, but maybe it's not worth the extra
>> code. I think the only case where you could really notice the difference
>> is for an equality search operator, which might end up doing a lot more
>> work in non-C collations (full-blown strcoll vs memcmp).

> I don't have a full understanding of this particular problem, but it
> sounds to me that that would be a non-issue due to the equality
> fast-path added to varstr_cmp() several years ago. I microbenchmarked
> it quite extensively at the time, and concluded that it was all but
> free in cases where it didn't work out.

I'm not following --- varstr_cmp has no way to know that we only
care about equality vs inequality. Yes, it might give back an
answer quickly when the strings are equal, but when they aren't,
it has to decide which is greater. In this case we don't care,
so long as the search operator is "=".

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2018-04-16 19:58:52 Re: Wrong Results from SP-GiST with Collations
Previous Message Peter Geoghegan 2018-04-16 19:39:54 Re: Wrong Results from SP-GiST with Collations