Re: Wrong Results from SP-GiST with Collations
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Emre Hasegeli <emre@hasegeli.com>, Teodor Sigaev <teodor@sigaev.ru>,
PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Date: 2018-04-16T19:55:52Z
Lists: pgsql-bugs
Peter Geoghegan <pg@bowt.ie> writes: > On Mon, Apr 16, 2018 at 12:28 PM, Tom Lane <tgl@sss.pgh.pa.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
Commits
-
Fix broken collation-aware searches in SP-GiST text opclass.
- b15e8f71dbf0 11.0 landed
- d90b2904c711 9.6.9 landed
- cf73a5b34a90 9.3.23 landed
- 93053aca5400 9.5.13 landed
- 608d1f97114d 9.4.18 landed
- 3397c67272e2 10.4 landed
-
Add prefix operator for TEXT type.
- 710d90da1fd8 11.0 cited