From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Propose RC1 for Friday ... |
Date: | 2002-11-14 17:34:31 |
Message-ID: | 1526.1037295271@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> Sorry to be a pest, but I'd like to re-raise the issue I brought up
> regarding a performance regression from 7.2.3, when subqueries are pulled
> up and merged with their parent.
> ...
> Tom was not excited about making the original change (we don't guarantee
> the order of WHERE clauses, which is what would be required for this to
> be a real fix), and is resisting changing it back, partly because neither
> order is the right thing. My argument is that we can't do the right thing
> right now, anyway (feature freeze), so let's put it back the way it was in
> the last stable release, so as not to break (o.k., dramatically slow down)
> existing queries.
Well, we could define it as a bug ;-) --- that is, a performance regression.
I'd be happier about adding a dozen lines of code to sort quals by
whether or not they contain a subplan than about flip-flopping on the
original patch. That would actually solve the class of problem you
exhibited, whereas the other is just a band-aid that happens to work for
your particular example.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-11-14 17:45:51 | Re: create or replace view |
Previous Message | Bruno Wolff III | 2002-11-14 17:22:59 | Re: create or replace view |