From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Partitioning WIP patch |
Date: | 2015-02-26 18:18:16 |
Message-ID: | 54EF6368.2030000@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/25/2015 07:15 PM, Amit Langote wrote:
> On 26-02-2015 AM 05:15, Josh Berkus wrote:
>> On 02/24/2015 12:13 AM, Amit Langote wrote:
>>> Here is an experimental patch that attempts to implement this.
>>
>> This looks awesome.
>
> Thanks!
>
>> I would love to have it for 9.5, but I guess the
>> patch isn't nearly baked enough for that?
>>
>
> I'm not quite sure what would qualify as baked enough for 9.5 though we
> can surely try to reach some consensus on various implementation aspects
> and perhaps even get it ready in time for 9.5.
Well, we don't have long at all to do that. I guess I'm asking what
kind of completeness of code we have; is this basically done pending API
changes and bugs, or are there major bits (like, say, pg_dump and
EXPLAIN support) which are completely unimplemented?
>>> where key_spec consists of partition key column names and optional
>>> operator class per column. Currently, there are restrictions on the
>>> key_spec such as allowing only column names (not arbitrary expressions
>>> of them), only one column for list strategy, etc.
>>
>> What's the obstacle to supporting expressions and/or IMMUTABLE
>> functions? I think it's fine to add this feature without them
>> initially, I'm just asking about the roadmap for eventually supporting
>> expressions in the key spec.
>>
>
> Only one concern I can remember someone had raised is that having to
> evaluate an expression for every row during bulk-inserts may end up
> being pretty expensive. Though, we might have to live with that.
Well, it's not more expensive than having to materialize the value from
a trigger and store it on disk. The leading one here would be functions
over timestamp; for example, the data has a timestamptz, but you want to
partition by week.
>
> I think one idea is to learn from ability to use expressions in indexes.
Sure. So a feature to implement for the 2nd release.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-02-26 18:20:14 | Re: How to create virtual indexes on postgres |
Previous Message | Josh Berkus | 2015-02-26 18:11:41 | Re: mogrify and indent features for jsonb |