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
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 fea
On Fri, Feb 13, 2015 at 3:13 PM, Jim Nasby wrote:
>
> 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.
That would not be true in our case. The data is not at all evenly
distributed
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 us
On Mon, Feb 09, 2015 at 12:37:05PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane 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
> >> arbit
On Mon, Feb 9, 2015 at 7:54 PM, Amit Langote
wrote:
>> 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 scatte
On Mon, Feb 09, 2015 at 12:37:05PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > 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
>
On 10-02-2015 AM 02:37, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane 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 fashi
On Mon, Feb 9, 2015 at 12:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane 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 complic
Robert Haas writes:
> On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane 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
>>
On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane 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 ha
Amit Langote 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?
Ab
Heikki Linnakangas writes:
> On 02/09/2015 03:21 AM, 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
>>
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
On 02/09/2015 03:21 AM, Tom Lane wrote:
Amit Langote writes:
On 07-02-2015 AM 12:10, Tom Lane wrote:
There is no good reason to assume that a range type exists at all, much
less that it is unique for a subtype. (Read the CREATE TYPE documentation
if you're unclear as to why not.) You have no
Amit Langote writes:
> On 07-02-2015 AM 12:10, Tom Lane wrote:
>> There is no good reason to assume that a range type exists at all, much
>> less that it is unique for a subtype. (Read the CREATE TYPE documentation
>> if you're unclear as to why not.) You have not said what you're trying to
>> a
On 07-02-2015 AM 12:10, Tom Lane wrote:
> Amit Langote writes:
>> I wonder why I cannot find a way to get a range type for a given (sub-)
>> type. I would like to build a RangeType from Datum's of lower and upper
>> bounds. Much like how construct_array() builds an ArrayType from a Datum
>> array
Amit Langote writes:
> I wonder why I cannot find a way to get a range type for a given (sub-)
> type. I would like to build a RangeType from Datum's of lower and upper
> bounds. Much like how construct_array() builds an ArrayType from a Datum
> array of elements given elements' type info.
> Is t
Horiguchi-san,
On 06-02-2015 PM 04:34, Kyotaro HORIGUCHI wrote:
> Hi, from nearby:)
>
Thank you!
>> I wonder why I cannot find a way to get a range type for a given (sub-)
>> type. I would like to build a RangeType from Datum's of lower and upper
>> bounds. Much like how construct_array() buil
Hi, from nearby:)
> I wonder why I cannot find a way to get a range type for a given (sub-)
> type. I would like to build a RangeType from Datum's of lower and upper
> bounds. Much like how construct_array() builds an ArrayType from a Datum
> array of elements given elements' type info.
>
> Is th
Hi,
I wonder why I cannot find a way to get a range type for a given (sub-)
type. I would like to build a RangeType from Datum's of lower and upper
bounds. Much like how construct_array() builds an ArrayType from a Datum
array of elements given elements' type info.
Is there some way I do not seem
21 matches
Mail list logo
