Mark Hills writes:
> I hadn't realised that sub-queries restrict the planner so much. Although
> at some point I've picked up a habit of avoiding them, presumably for this
> reason.
> If you have time to explain, I'd be interested in a suggestion for any
> change to the planner that could make
On Sun, 26 Feb 2012, Tom Lane wrote:
> Mark Hills writes:
> > What is that prevents the index condition from being used in earlier parts
> > of the query? Only where a single condition is present is it be used below
> > the final join.
>
> "WHERE job.jid IN (1234)" is simplified to "WHERE job.
Mark Hills writes:
> What is that prevents the index condition from being used in earlier parts
> of the query? Only where a single condition is present is it be used below
> the final join.
"WHERE job.jid IN (1234)" is simplified to "WHERE job.jid = 1234", and
that in combination with "JOIN ON
I found in a production system that mostly the performance is being
crippled by the handling of one particular case.
I hope I've reduced this to a minimal example, below.
Summary: when more than one key is given (or the data is sourced from a
table) the planner is forced to a join of the whole
