On Mon, Jan 14, 2008 at 10:45:28PM -0500, Tom Lane wrote:
> Jeff Cohen <[EMAIL PROTECTED]> writes:
> > In the proposed solution, hash and list partitions work for all types  
> > that support an equality operator, and range partitions work for all  
> > types that support fully-ordered comparison.
> 
> Surely a hashing method would require a *hashable* equality operator,
> ie a hash opclass; likewise range partitions would demand a matching
> btree opclass.  You could do list partitions with an equality operator
> of either kind.

Right.

> 
> Essentially all of the system's current knowledge about the properties
> of specific operators is encoded as operator classes for one of these
> two built-in index types.  If you want to make assumptions about the
> behavior of an operator, it really needs to be founded on these types of
> opclasses --- or else you're buying into inventing a comparable amount
> of infrastructure for some other organizational concept.

Right, we obviously don't want to do that.

> 
> I think Peter's point was that you might want to think about
> generalizing your concepts so that other kinds of operator classes could
> someday serve as the foundations for other kinds of partitioning rules.

Let me see if I've understood: certain operator classes either describe
or allow certain kinds of partitioning: hash is obvious, btree allows
equality and range based approaches, gist allows users a whole range of
possibilities. So, a truly extensible system would define the
partitioning type in the catalog?

That's an interesting idea. It presents problems, I think, for the
grammar I've proposed because some grammatical constructs are tied to
range, some to hash, some to list. Any insights into how we could
achieve both?

Thanks,

Gavin

PS: Heading off into the French country side for a little while and responses
may be a little slow.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to