From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RangeType internal use |
Date: | 2015-02-10 20:04:42 |
Message-ID: | 20150210200442.GB1952@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 09, 2015 at 12:37:05PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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).
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.
> 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.
Agreed.
> Whatever we support, the behavior needs to be described by *one*
> chunk of information --- a sorted list of bin bounding values,
> perhaps.
This would work for some interesting generalization of "sorted."
Maybe going back to the mathematical definition of "partition" could
bear more fruit. All that's needed for that is an equivalence
relation, however it's denoted. In practical terms, you'd need to
have a quick way to enumerate the equivalence classes and another to
establish whether equivalence holds.
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-02-10 20:09:35 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |
Previous Message | Tom Lane | 2015-02-10 20:00:35 | Manipulating complex types as non-contiguous structures in-memory |