cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [ESQL] Improvement....
Date Tue, 28 Jan 2003 15:41:32 GMT

-----Original Message-----
From: Niclas Hedhman [] 
Sent: Monday, January 27, 2003 11:03 PM
Subject: Re: [ESQL] Improvement....

On Tuesday 28 January 2003 01:32, Hunsberger, Peter wrote:
> >> if (exist <esql:more-results>)
> >>    LIMIT 5+1
> >> else
> >>    LIMIT 5
> >>
> >> I think this is an elegant solution. What you think?
> >
> > Sure - but the problem is that we also would need to adjust the 
> > length of the resultset inside the helper class. (you always want to 
> > see only 5 rows in your page)
> >
> > The length of the resultset inside the class would sometimes be one 
> > more and sometimes *exact* - depending on whether there is a 
> > <more-results> tag or not. Which would be very confusing!
> >
> > Give me a day to think about this...
> Torsten,
> You're chasing a non-existent problem.  There is never a real life 
> case that will have both good performance for N records and bad 
> performance for
> N+1 records.  The only way you can guarantee having good performance 
> N+for N
> records is if you can build an index.  If you can build an index then 
> the search will always terminate after looking at N+1 records.

I give you a "real world" case;

In natural language;
Give me the first COLOR (3D point) which resides not further than dE units 
from COLOR [L1, a1, b1].

In SQL database, I can only place the L, a, b columns, individually, and the

spherical search would be;

WHERE SQRT( SQ( L - L1 ) + SQ( a - a1) + SQ( a - a2 ) ) < dE

where L1, a1, b1 and dE are parameters given at the invocation of the Select


I could go into a long discussion how this could be optimized, both in SQL 
(multi-levelled subqueries and regeneration of indexes) and internal to the 
DB engine (3D indecies), but I won't.

If I have a well populated database, evenly and randomly spread out, I will
the average have a 100% penalty on LIMIT N+1, as the search will go through 
roughly the same number of records to find the "next one", which I don't


To unsubscribe, e-mail:
For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message