| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:39:54 |
| Message-ID: | CAH2-WznG1-gnBcHuSDNd=u+1oYiJHkN75P-m9cNkN7aP9j4v5Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, Apr 16, 2018 at 12:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Right. Alternatively, you could actually call varstr_cmp() within the
>> "non-collation-aware" branch.
>
> 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.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-04-16 19:55:52 | Re: Wrong Results from SP-GiST with Collations |
| Previous Message | Tomas Vondra | 2018-04-16 19:31:08 | Re: Standby corruption after master is restarted |