Re: Query planner ignoring constraints on partitioned tables when joining

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Okner <michael(dot)okner(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Query planner ignoring constraints on partitioned tables when joining
Date: 2013-05-02 12:41:14
Message-ID: CA+U5nMLOAA4Jw2OQamQggem5-k1pwc27utAbcw9DqzUEjfRQtw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 18 April 2013 22:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> One could imagine adding planner logic that would make inferences of a
> similar sort for equalities combined with inequalities, but it would be
> vastly more complicated, and would provide useful results in vastly
> fewer queries, than the equality-propagation logic. So don't hold your
> breath waiting for something like that to happen.

I'll take note that we need to make partitioning work for merge joins also.

On a more general note, it would be good to be able to look at the
starting value from the driving table of the join and use that as a
constraint in the scan on the second table. We rely on that mechanism
for nested loop joins, so we could do with that here also.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2013-05-02 12:48:34 Re: "WHERE 1 = 2 OR ..." makes planner choose a very inefficient plan
Previous Message Simon Riggs 2013-05-02 12:27:28 Re: In progress INSERT wrecks plans on table