On 10-02-2015 AM 02:37, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> It's going to be complicated and probably buggy, and I think it is heading >>> in the wrong direction altogether. If you want to partition in some >>> arbitrary complicated fashion that the system can't reason about very >>> effectively, we *already have that*. IMO the entire point of building >>> a new partitioning infrastructure is to build something simple, reliable, >>> and a whole lot faster than what you can get from inheritance >>> relationships. And "faster" is going to come mainly from making the >>> partitioning rules as simple as possible, not as complex as possible. > >> Yeah, but people expect to be able to partition on ranges that are not >> all of equal width. I think any proposal that we shouldn't support >> that is the kiss of death for a feature like this - it will be so >> restricted as to eliminate 75% of the use cases. > > Well, that's debatable IMO (especially your claim that variable-size > partitions would be needed by a majority of users). But in any case, > partitioning behavior that is emergent from a bunch of independent pieces > of information scattered among N tables seems absolutely untenable from > where I sit. Whatever we support, the behavior needs to be described by > *one* chunk of information --- a sorted list of bin bounding values, > perhaps. >
I'm a bit confused here. I got an impression that partitioning formula as you suggest would consist of two pieces of information - an origin point & a bin width. Then routing a tuple consists of using exactly these two values to tell a bin number and hence a partition in O(1) time assuming we've made all partitions be exactly bin-width wide. You mention here a sorted list of bin bounding values which we can very well put together for a partitioned table in its relation descriptor based on whatever information we stored in catalog. That is, we can always have a *one* chunk of partitioning information as *internal* representation irrespective of how generalized we make our on-disk representation. We can get O(log N) if not O(1) from that I'd hope. In fact, that's what I had in mind about this. Did I read it wrong? 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