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.