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
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 |