Re: Extending opfamilies for GIN indexes

Tom Lane <tgl@sss.pgh.pa.us> writes:
> I think you missed the point: right now, to use both the core and
> intarray operators on an integer[] column, you have to create *two*
> GIN indexes, which will have exactly identical contents.  I'm looking
> for a way to let intarray extend the core opfamily definition so that
> one index can serve.

That I think I understood, but then I mixed opfamily and opclasses
badly.  Let's try again.

For the GIN indexes, we have 2 methods for building the index and 3
others to search it to solve the query.  You're proposing that the 2
former methods would be in the opfamily and the 3 later in the opclass.

We'd like to be able to use the same index (which building depends on
the opfamily) for solving different kind of queries, for which we can
use different traversal and search algorithms, that's the opclass.

So we would want the planner to know that in the GIN case an index built
with any opclass of a given opfamily can help answer a query that would
need any opclass of the opfamily.  Right?

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support