Postgres Pro
Downloads
Home   >   mailing lists

Thread: GIN: Implementing triConsistent and strategy number

GIN: Implementing triConsistent and strategy number

From
Jeff Janes
Date:
Is there a way to implement triConsistent for only some of the strategy numbers?

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?

Thanks,

Jeff

Re: GIN: Implementing triConsistent and strategy number

From
Heikki Linnakangas
Date:
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. Do you have a real-world example of 
where that'd be useful?

- Heikki

Re: GIN: Implementing triConsistent and strategy number

From
Jeff Janes
Date:
On Fri, Jun 26, 2015 at 7:13 AM, Heikki Linnakangas <hlinnaka@iki.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