"=?utf-8?b?RG91ZyBHb3JsZXk=?=" <doug@xxxxxxxxx> writes:
> I'm attempting to implement table partitioning with constraint exclusions,
> but I'm not seeing the planner limit the plan to an appropriate set of
> child tables. I'm wondering if the functions in my constraints are making
> the exclusion impossible.
> My constraints look like this:
> Â Â Â ALTER TABLE response_data.queries_response_2015w23
> Â Â Â Â Â ADD CONSTRAINT queries_response_2015w23_timestamp_check
> Â Â Â Â Â Â Â Â Â CHECK (
> Â Â Â Â Â Â Â Â Â Â Â Â date_part('year'::text, "timestamp"::timestamp without time zone) = 2015::double precision AND
> Â Â Â Â Â Â Â Â Â Â Â Â date_part('week'::text, "timestamp"::timestamp without time zone) = 23::double precision
> Â Â Â Â Â Â Â Â Â );
> And my query looks like this:
> Â Â Â explain select * from public.queries_response where age("timestamp"::timestamp) < '24 hours';
> Â Â Â
> http://www.postgresql.org/docs/9.4/static/ddl-partitioning.html gives this caveat:
> Â Â Â "Constraint exclusion only works when the query's WHERE clause contains
> Â Â Â constants (or externally supplied parameters). For example, a comparison
> Â Â Â against a non-immutable function such as CURRENT_TIMESTAMP cannot be
> Â Â Â optimized, since the planner cannot know which partition the function
> Â Â Â value might fall into at run time."
> Â Â Â
> Will I likely need to replace the date_part functions with actual dates to
> make this work?
Well, you can't make it work like that, for sure. The planner has no clue
that there's any connection between age() and date_part(). And if it did
fully understand that relationship, it still would refuse to do constraint
exclusion in this example, because the age() constraint is
current-timestamp-dependent. It couldn't assume that now() when executing
the query is the same as it was when planning the query, so it wouldn't
know which partition to select.
Worse still, if I'm right in guessing that the timestamp column is
timestamp WITH time zone (if it isn't, why are you bothering with the
casts?) then the check constraints themselves aren't immutable, because
their effective behavior depends on the current setting of TimeZone.
So the planner will refuse to make any deductions at all with them.
You'd be much better off using child-table constraints like
"timestamp" >= '2015-01-01' AND "timestamp" < '2015-01-08'
because the planner can reason about them. But I'm afraid the age()
technique still loses.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
