Re: View's plan not taking advantage of WHERE?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mike Summers <msummers57(at)gmail(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: View's plan not taking advantage of WHERE?
Date: 2013-06-05 14:16:35
Message-ID: 22167.1370441795@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Mike Summers <msummers57(at)gmail(dot)com> writes:
> Other than the tests in the original post do you have any suggestions?

If you're speaking of
http://www.postgresql.org/message-id/CAJGeMG89QbDxMab7-aPD_yXVsGx7Q=auXYM9UFVaq06cRZ4E2A@mail.gmail.com
that has nothing to do with cached plans, obsolete or otherwise.
You seem to be wishing that the planner would deduce "x = constant" from
"aggregate_function(x) = constant", which is wrong on its face.
AFAICS it's not even correct for the special case that the aggregate
function is first_not_null(), since you have multiple occurrences of
that in the view and there's no certainty that they all choose to return
values from the same row.

Even if the optimization is valid given some additional assumptions that
you've not told us, it's going to be a sufficiently narrow case that
I doubt we'd ever be willing to expend planner cycles on checking for it.

If you want WHERE clauses to be pushed down into this query you need to
think of some other way to define the query. Perhaps something
involving GROUP BY or DISTINCT instead of first_not_null() would be more
amenable to optimization.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mike Summers 2013-06-05 14:36:43 Re: View's plan not taking advantage of WHERE?
Previous Message Raymond O'Donnell 2013-06-05 12:27:37 Re: How to modify dump files created by pg_dump