Re: Re: How can i monitor exactly what (partition) tables are accessed by a query? - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Re: How can i monitor exactly what (partition) tables are accessed by a query?
Date
Msg-id AE03398D-119D-412B-9DF5-1EC8770474F3@gmail.com
Whole thread Raw
In response to Re: Re: How can i monitor exactly what (partition) tables are accessed by a query?  (Robert Nix <robert@urban4m.com>)
Responses Re: How can i monitor exactly what (partition) tables are accessed by a query?
List pgsql-general
On 19 Sep 2014, at 3:50, Robert Nix <robert@urban4m.com> wrote:

> Thanks, David.
>
> 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,
sincethe 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
wayI did. 

What may be worth a try is to join against a UNION ALL of your partitions, with each section of the UNION having an
explicirtWHERE clause matching your partitioning constraints. 
The idea there is that such a UNION could provide the explicit constant WHERE clauses that your JOIN implicitly depends
on.

If that works, then the next step would be to try a VIEW using that UNION, which - assuming you automatically generate
yourpartition tables - could be created at the same moment that you create new partitions. 

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.



pgsql-general by date:

Previous
From: Philipp Kraus
Date:
Subject: cloning database
Next
From: David G Johnston
Date:
Subject: Re: Reserved keywords and qualified identifiers