From: | Gavin Sherry <swm(at)alcove(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Cohen <jcohen(at)greenplum(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Mike <ipso(at)snappymail(dot)ca> |
Subject: | Re: Declarative partitioning grammar |
Date: | 2008-01-18 07:35:41 |
Message-ID: | 20080118073541.GF15295@europa.idg.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 14, 2008 at 10:45:28PM -0500, Tom Lane wrote:
> Jeff Cohen <jcohen(at)greenplum(dot)com> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-01-18 08:23:26 | Re: Simple thing to make pg_autovacuum more useful |
Previous Message | Joshua D. Drake | 2008-01-18 03:19:28 | Re: Simple thing to make pg_autovacuum more useful |