On 12/15/2014 10:55 AM, Robert Haas wrote:
>> This means if a user puts arbitrary expressions in a partition definition, say,
>> >
>> > ... FOR VALUES extract(month from current_date) TO extract(month from current_date + interval '3 months'),
>> >
>> > we make sure that those expressions are pre-computed to literal values.
> I would expect that to fail, just as it would fail if you tried to
> build an index using a volatile expression.
Yes, I wasn't saying that expressions should be used when *creating* the
partitions, which strikes me as a bad idea for several reasons.
Expressions should be usable when SELECTing data from the partitions.
Right now, they aren't, because the planner picks parttiions well before
the rewrite phase which would reduce "extract (month from current_date)"
to a constant.
Right now, if you partition by an integer ID even, and do:
SELECT * FROM partitioned_table WHERE ID = ( 3 + 4 )
... postgres will scan all partitions because ( 3 + 4 ) is an expression
and isn't evaluated until after CE is done.
I don't think there's an easy way to do the expression rewrite while
we're still in planning, is there?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com