| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: RangeType internal use |
| Date: | 2015-02-09 15:42:45 |
| Message-ID: | 15562.1423496565@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> 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?
Absolutely. Anything else is not scalable; it's just another flavor of
the inheritance + CHECK constraint mechanism. The entire point of doing a
new partitioning design IMO is to get away from that. It should be
possible to determine which partition a row belongs to in O(1) time, not
O(N).
> 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?
Yeah, I would think so.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-02-09 15:56:43 | Re: New CF app deployment |
| Previous Message | Tom Lane | 2015-02-09 15:36:03 | Re: RangeType internal use |