Re: GIN: Implementing triConsistent and strategy number

On Fri, Jun 26, 2015 at 7:13 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> On 06/24/2015 11:11 PM, Jeff Janes wrote:
>
>> Is there a way to implement triConsistent for only some of the strategy
>> numbers?
>>
>
> No.
>
> It looks like I would have to internally re-implement something like
>> shimTriConsistentFn for each strategy number for which I don't want to
>> implement the ternary system in full. Am I missing a trick?
>>
>
> Hmm. It didn't occur to me that you might want to implement tri-consistent
> for some strategy numbers and fall back to the shim-implementation for
> others.

I didn't really want to fall back to shim-implementation for executing the
query, but I didn't see other general options. I could define a new
operator class with just the operators I want to support triconsistent on,
but then I think I would need to build the same index once for the old
class and once for the new class.

If it could learn that triconsistent is not supported for a certain
strategy, it could set
key->nrequired = key->nentries
And then use the binary consistent function.

> Do you have a real-world example of where that'd be useful?

I wanted to make pg_trgm support triconsistent for LIKE queries, to see if
that would speed things up on a few cases, but didn't want to mess around
with regexp or similarity until I was sure it was worthwhile. I can make
them throw an error if invoked for now. In this case if it is worth it to
do for LIKE, it will probably be worth it for the other ones as well, so it
is more an issue of incremental development and testing rather than the
final state.

Cheers,

Jeff