On 09-02-2015 AM 10:21, Tom Lane wrote: > > Meh. I don't care for that much --- it sounds a lot like deciding that > your problem is a nail because there is a hammer within reach. A random > collection of ranges doesn't seem like a very appropriate representation > to me; first because there is no simple way to enforce that it partitions > the key space (no overlaps and no missing portions), and second because it > provides little purchase for efficient tuple routing algorithms. The best > you could possibly hope for is some log-N tree search mechanism, and that > would require a fair amount of setup beforehand. > > I'd rather insist that range partitioning be done on the basis of an > origin point and a bin width, which would allow trivial computation of > which bin number any given key falls in. This will limit the set of types > it can be done over, for sure, but not more than depending on built-in > range types would. >
Okay, let me back up a little and think about your suggestion which I do not seem to understand very well - it raises a few questions for me: does this mean a partitioning criteria is associated with parent (partitioned table) rather than each individual partition? I would guess that bin width is partition interval such that each bin number gives partition number (of equal-sized consecutively numbered partitions without gaps). But I don't quite understand what origin point is? Is that a key literal value from which to begin counting bins and if so, is it stored in catalog as part of the partitioning rule? Does this affect the syntax to use when defining partitioned table/partitions like: CREATE TABLE parent PARTITION BY RANGE ON (col1) EVERY '3 months'::interval; CREATE TABLE child PARTITION 1 OF parent; or some such? Or may I ask if is is just an internal representation geared towards optimizing range partitioning whereas on-disk representation is something more generalized allowing for other partitioning strategies to be implemented as well? Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
