Re: [HACKERS] What about LIMIT in SELECT ?

Hannu Krosing wrote:

> Jan Wieck wrote:
> > The speedup for the cursor/fetch scenario is so impressive
> > that I'll create a post 6.4 patch. I don't want it in 6.4
> > because there is absolutely no query in the whole regression
> > test, where it suppresses the sort node.
>
> Good, then it works as expected ;)
>
> More seriously, it is not within powers of current regression test
> framework to test speed improvements (only the case where
> performance-wise bad implementation will actually crash the backend,
> as in the cnfify problem, but AFAIK we dont test for those now)
>
> > So we have absolutely no check that it doesn't break anything.
>
> If it did pass the regression, then IMHO it did not break anything.

Thats the point. The check if the sort node is required
returns TRUE for ALL queries of the regression. So the
behaviour when it returns FALSE is absolutely not tested.

>
> I would vote for putting it in (maybe with a
> 'set fix_optimiser_stupidity on' safeguard to enable it). I see no
> reason to postpone it to 6.4.1 and force almost everybody to first
> patch their copy and then upgrade very soon.
>
> I would even go far enough to call it a bugfix, as it does not really
> introduce any new functionality only fixes some existing functionality
> so that much bigger databases can be actually used.

I can't call it a bugfix because it is only a performance win
in some situations. And I feel the risk is too high to put
untested code into the backend at BETA2 time. The max we
should do is to take this one and the LIMIT thing (maybe
implemented as I suggested lately), and put out a Web-
Performance-Release at the same time we release 6.4.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #