From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Query plan question, and a memory leak |
Date: | 2003-02-03 17:02:56 |
Message-ID: | 874r7l9u0v.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Is there some way to force the optimizer not to substitute the subquery in the
> > where clause?
>
> You could try tinkering with the rules for invoking subquery_push_qual
> in src/backend/optimizer/path/allpaths.c. This might be a case that
> would fall under the note there wondering if pushing down can ever
> result in a worse plan. I'm not sure though that we can tell the
> difference reliably...
Indeed changing
select * from (select <subquery> as foo) where foo is not null
into
select * from (select <subquery> as foo) where (select foo) is not null
causes that code path to give up on inlining the subplan.
Thanks for the pointer to the part of the code involved.
Perhaps it should check not just whether the where clause involves a subplan
but also whether expression it's substituting involves a subplan? There may be
cases where it would be advantageous to inline a sub plan though, it just
seems like it wouldn't be the majority.
I guess in an ideal world the optimizer would consider both possibilities and
choose based on the cost. Does the optimizer only use the costs for choosing
join orders and methods and not for deciding whether to make other
transformations?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-02-03 17:03:26 | Re: Dferred constraints not deferred? |
Previous Message | Nigel J. Andrews | 2003-02-03 16:58:30 | Re: DBI driver and transactions |