Re: RangeType internal use
От | Tom Lane |
---|---|
Тема | Re: RangeType internal use |
Дата | |
Msg-id | 28417.1423503425@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: RangeType internal use (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RangeType internal use
Re: RangeType internal use Re: RangeType internal use Re: RangeType internal use |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane <tgl@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. regards, tom lane
В списке pgsql-hackers по дате отправления: