Re: RangeType internal use

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: RangeType internal use
Дата
Msg-id 54DFB203.8000607@BlueTreble.com
обсуждение исходный текст
Ответ на Re: RangeType internal use  (David Fetter <david@fetter.org>)
Список pgsql-hackers
On 2/13/15 3:34 PM, David Fetter wrote:
> On Fri, Feb 13, 2015 at 03:13:11PM -0600, Jim Nasby wrote:
>> On 2/10/15 2:04 PM, David Fetter wrote:
>>>>>>> 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).
>>> It's ubiquitous.
>>>
>>> Time range partition sets almost always have some sets with finite
>>> range and at least one range with infinity in it: "current end" to
>>> infinity, and somewhat less frequently in my experience, -infinity
>>> to some arbitrary start.
>>
>> We could instead handle that with a generic "this doesn't fit in any
>> other partition" capability. Presumably that would be easy if we're
>> building this on top of inheritance features.
>>
>> If we exclude the issue of needing one or two oddball partitions for
>> +/- infinity, I expect that fixed sized partitions would actually
>> cover 80-90% of cases.
>
> Is "partition the domain" really that big an ask?
]
Since this debate has been running for a few months, perhaps it is. I'd 
rather see limited partitioning get in sooner and come back to handle 
the less common cases (as long as we don't paint ourselves in a corner).
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: New CF app deployment
Следующее
От: Robert Haas
Дата:
Сообщение: Re: restrict global access to be readonly