On Wed, Nov 13, 2002 at 11:43:14PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > "Marc G. Fournier" <scrappy@hub.org> writes:
> > > It seems to me that about the only major issue right now is testing the
> > > various platforms ... would anyone disagree with putting out an RC1 on
> > > Friday whose primary purpose is platform testing?
> >
> > Works for me. We should be able to resolve this awk issue by then,
> > and hopefully have confirmation on that GB18030 change too.
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. What happened is that the default order
that WHERE clauses get merged changed. (The original discussion and
patch was over on GENERAL, and doesn't seem to be in the FTS archives?):
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3D0885E1.8F369ACA%40mascari.com&rnum=3&prev=/groups%3Fq%3DMike%2BMascari%2Bsecurity%2BTom%2BLane%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den
The reason for doing this was a theoretical hole in VIEW-based data access
restrictions. The consequence is that a class of queries got an order
of magnitude slower (my particular example goes from 160 ms to 2000 ms).
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. (patch attached)
Any other opinions?
Ross
