Re: knngist - 0.8

Teodor Sigaev <teodor@sigaev.ru> writes:
> As I remember, there were several suggested designs:
> 1) 5-th boolean column (amopfamily, amoplefttype, amoprighttype, amopstrategy, 
> amoporder) to point kind of operator (search or order)
>    + saves one record for operator in pg_amop
>    - operator could not be used in both roles
>    - increase number of arguments for syscache machinery
> 2) 5-th combined column, which contains some kind of flag for each role
>    + saves one record for operator in pg_amop
>    + operator could be used in both roles
>    - strategy number for operator is the same for both roles, it's unacceptable
>      because GiST's consistentFn will not have information about role. GiST
>      itself could distinguish them by invented SK_ORDER flag. So, this
>      requires to introduce one more argument for consistentFn, while it
>      already has 5 arguments.
>    - increase number of arguments for syscache machinery
> 3) 3-rd boolean column (amopopr, amopfamily, amoporder)
>    - could be two records per operator
>    + operator could be used in both roles
>    + strategy number could be different for different roles

How can #3 work at all?  It's ignoring a couple of critical index
columns.  In particular, I believe the sticking point here is this
unique index:
   "pg_amop_fam_strat_index" UNIQUE, btree (amopfamily, amoplefttype, amoprighttype, amopstrategy)

#3 doesn't explain what to do about this index.  If we extend it to
five columns, as we'd logically have to do to preserve uniqueness,
then the associated syscache has to have five key columns as well,
and now we're at solution #1.

I'm not terribly thrilled with using a boolean here in any case.
Now that we have two "roles" an operator might play in an opclass,
who's to say there might not be more roles someday?  We should use
a column type that will support more than two roles without basic
rejiggering.

BTW, have we discussed the idea of embedding the role in the strategy
number?  For example, require regular operators to have strategy
numbers 1-9999, while ordering operators have numbers 10000-19999,
leaving room for a couple more roles before we have to rethink the
assignment or widen amopstrategy to an int.  That's a bit ugly but
might be better than adding a separate role column.
        regards, tom lane