Re: horizontal partition - Mailing list pgsql-performance

From Tom Lane
Subject Re: horizontal partition
Date
Msg-id 12896.1107413728@sss.pgh.pa.us
Whole thread Raw
In response to Re: horizontal partition  (Josh Berkus <josh@agliodbs.com>)
Responses Re: horizontal partition  (Gaetano Mendola <mendola@bigfoot.com>)
List pgsql-performance
Josh Berkus <josh@agliodbs.com> writes:
> The issue here is that the planner is capable of "pushing down" the WHERE
> criteria into the first view, but not into the second, "nested" view, and so
> postgres materializes the UNIONed data set before perfoming the join.

> Thing is, I seem to recall that this particular issue was something Tom fixed
> a while ago.  Which is why I wanted to know what version Gaetano is using.

It's still true that we can't generate a nestloop-with-inner-indexscan
join plan if the inner side is anything more complex than a single table
scan.  Since that's the only plan that gives you any chance of not
scanning the whole partitioned table, it's rather a hindrance :-(

It might be possible to fix this by treating the nestloop's join
conditions as "push down-able" criteria, instead of the present rather
ad hoc method for generating nestloop/indexscan plans.  It'd be quite
a deal of work though, and I'm concerned about how slow the planner
might run if we did do it like that.

            regards, tom lane

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: horizontal partition
Next
From: Michael Fuhr
Date:
Subject: Re: Accessing insert values in triggers