Re: Query plan question, and a memory leak

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 05:53:39
Message-ID: 87adhdap0c.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:
> > However I tested those queries with some data and things really do seem to be
> > behaving oddly. It takes nearly twice as long to run the version with the
> > where clause and duplicate subplan.
>
> Yes, they will both be executed --- there's no
> duplicate-subexpression-elimination logic...

But, but, there was no common subexpression in the original query. The only
common subexpression was introduced by the optimizer itself at some point.

The query was of the form
"select * from (select <subquery> as foo) where foo is not null".

Is there some way to force the optimizer not to substitute the subquery in the
where clause? I mean, I can't do a materialize, I don't have the temporary
space for all the records, but is there some way to get it to assemble the
data for the single record and then apply the where clause on that?

Thanks again for all the help. I'm sorry if I'm becoming a pest but this query
may be really important to my project.

--
greg

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ryan VanderBijl 2003-02-03 06:21:01 Re: serialization errors
Previous Message Tom Lane 2003-02-03 05:22:22 Re: Query plan question, and a memory leak