GIST and GIN currently set their amstrategies entries to 100, which is
a completely arbitrary number, since these index AMs don't impose any
particular interpretation on operator strategy numbers. Usually it's
far too large and results in wasted space in relcache entries. But it's
not impossible that it could be too small for a complex opclass.

I propose that we should set pg_am.amstrategies to zero when the index
AM doesn't have a fixed interpretation of strategy numbers. This would
make it clearer that there's no intended upper bound. It would also
cause the relcache not to bother trying to preload operator numbers,
which saves time and space --- neither of these AMs ever actually look
at the rd_operator array in relcache entries.

Comments? Can anyone think of anything that is likely to break?
(I can only see one or two trivial code adjustments that would be
needed.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

> I propose that we should set pg_am.amstrategies to zero when the index
> AM doesn't have a fixed interpretation of strategy numbers. This would
> make it clearer that there's no intended upper bound. It would also

Agreed. BTW, that also plays around possibility of grouping operator classes -
since GIN/GiST hasn't fixed strategy numbers, they opclasses can not be unioned
into group without extra agreement.

> Comments? Can anyone think of anything that is likely to break?
> (I can only see one or two trivial code adjustments that would be
> needed.)
>
> regards, tom lane

--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Teodor Sigaev <teodor@sigaev.ru> writes:
>> I propose that we should set pg_am.amstrategies to zero when the index
>> AM doesn't have a fixed interpretation of strategy numbers. This would
>> make it clearer that there's no intended upper bound. It would also

> Agreed. BTW, that also plays around possibility of grouping operator
> classes - since GIN/GiST hasn't fixed strategy numbers, they opclasses
> can not be unioned into group without extra agreement.

Sure, but a group has to have agreement on semantics anyway ---
agreement on operator numbering would be part of that.

BTW, I've been looking at the built-in GIN array opclasses and wondering
if we couldn't make them a group. The advantage is that we'd need only
one pg_amop entry for each of the anyarray operators that are common to
all those classes. But you could also see that as a disadvantage,
because if the operators are "loose" in the group then there's no clear
indication that the individual opclasses depend on them. OTOH all these
entries will be marked pinned in pg_depend and so are undroppable, so
that disadvantage is largely academic.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate