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
