I have read that page many times but clearly I have forgotten this:
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 asCURRENT_TIMESTAMP cannot be optimized, since the planner cannot know which partition the function value might fall into at run time.
I had worked around this "issue" some time ago but I clearly should have documented _why_ I worked around it in the way I did.
> I'm experiencing a problem with queries apparently not using the check > constraints of my partition tables (tried constraint_exclusion =partition > and =on with same results) and explain isn't sufficient to diagnose the > issue because the value for the check constraint in the query comes from a > join condition. > > What i need is a way to see exactly what tables are actually accessed by > the query. > > When i hardcode the check constraint column's value into the query, the > explain plan reports what i expect it should be executing but the > performance of the query indicates that the partitions are not actually > being used when the check constraint value is obtained from a join > condition. > > Any and all help appreciated. > -- > .nix
Please provide a minimal schema and example query so we can explain exactly where your misunderstanding is coming from. Generally, though, a partiton must be excluded during plan time so the data in a table will not effect the final plan - only constants can do that.
