From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Klint Gore <kg(at)kgb(dot)une(dot)edu(dot)au>, Gaetano Mendola <mendola(at)bigfoot(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: horizontal partition |
Date: | 2005-02-03 06:55:28 |
Message-ID: | 12896.1107413728@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2005-02-03 08:01:42 | Re: [PERFORM] Accessing insert values in triggers |
Previous Message | Josh Berkus | 2005-02-03 06:41:57 | Re: horizontal partition |