| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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-09 17:32:08 |
| Message-ID: | CA+TgmobObyPr+oqUXNm+NO5FeLA9ZNJC8R+iRZuNJPDqMh5_-A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-02-09 17:37:05 | Re: RangeType internal use |
| Previous Message | Jan Urbański | 2015-02-09 17:17:14 | libpq's multi-threaded SSL callback handling is busted |