[ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Hi:

Some days ago I suggested a solution to fix the problem about how to
trigger the <esql:more-results> tag. The problem in question was related
to the use of the LIMIT clausule of SQL.

The proposed solution works fine in case you really have a big table and
need to check if there are (as the name of the tag) more results inside
the table.

But this solution have a side efect: a time penalization (downgrade of
database performance) in case you know the exactly the number of rows you
need to retrieve and does not care if there are more or not. Why? I will
try to explain it below:

<example A>

DESCRIPTION: You need to build pages containing 10 registers from a table
that currently have 10,000 registers and continue growing.

SOLUTION: Use,

<esql:max-rows>10</esql:max-rows>

COMMENTS: Currently the ESQL code will ask for 10+1 register in order to
know if there are more registers. He will write a query adding "LIMIT 11"

You will get your 10 registers and the 11th register is used to shot the
<esql:more-results> tag. You have no access to the 11th register. It is
used for internal purpose.
</example A>

<example B>
DESCRIPTION: You need to build a page and you know that there are EXACTLY 
10 registers from a table that currently have 10,000 registers and
continue growing.

SOLUTION: Same as example A. Use,

<esql:max-rows>10</esql:max-rows>

COMMENTS: Same as A.

</example B>

WHAT IS WRONG?

In example A all is OK.

In example B we are not using the power of the Database Manager.

WHY?

The LIMIT clause was designed to tell the database engine:

"Let find just X rows", then the database engine when it got the X rows
stop searching and return the X rows. It improves the response time, since
does not to continue searching!

Now think in a 10 million row table and YOU KNOW you need only 5 rows!

PROPOSED SOLUTION:

Change the code to something like

if (exist <esql:more-results>) /* we need fine if there are more rows */
    LIMIT X+1
else
    LIMIT X /* Since the user does not write a <esql:more-results> tag, he
does not care if there are more results or not. Lets find as many rows
as he asked */

Also we need to check the form that the <esql:more-results> is triggered.

I can write the Java code in detail and post it to review if you agree
with this proposal.

Best Regards,

Antonio Gallardo




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Christian Haul dijo:
> On 27.Jan.2003 -- 02:49 AM, Antonio Gallardo wrote:
>> Niclas Hedhman dijo:
>> > On Monday 27 January 2003 16:01, Torsten Curdt wrote:
>> >> Niclas Hedhman wrote:
>> >> > On Monday 27 January 2003 07:06, Torsten Curdt wrote:
>> >> >>>What do the database to try to find the 6th row?
>> >> >>>
>> >> >>>I think the answer is: scan the rest of the database after
>> finding
>> >> the ONLY 5 rows that already exist.
>> >> >>
>> >> >>No :) ...be sure - it doesn't
>> >> >
>> >> > Well, that depends on the WHERE clause. For instance;
>> >> >
>> >> > WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
>> >> >
>> >> > definately go through every record, whether the fields are
>> indexed
>> >> or not.
>
> That's really bad! No way to refactor the schema or the query? Or use a
> differen DBMS? E.g. in INFORMIX you can create an index based on a user
> defined function...
>
>> I have a table that store the status of some tickets. You always know
>> how many status there can be. If you said:
>>
>> 1-Open
>> 2-Close
>> 3-Invalid
>>
>> Then if you want to show the history, you will ask for LIMIT 3, but
>> the database will try to find the 4th row after finding the only 3
>> that can exist.
>>
>> This is why I told this is a performance issue. Not an error.
>
> Again I believe an index would help a lot more. With bad luck your three
> rows are spread all over the table and you're going to have a nearly
> complete table scan anyways.

This is not bad luck. ;-)
I cannot find an easy example. My queries envolves 5 or 7 tables. I have a
status table. This table contains the date, ticket and status. This is
because sometimes you search by status.

I recently read that this is not a good idea indexing a field with small
posibles values in a big table. That is my case. I am using Postgres, but
in general this is true.

Niclas pointed a example. I know this is not a good code, but the idea is
there. The point is: I know there are only 5 row, but the LIMIT clausule
will be written as:

LIMIT 6.

That will force to search the entire table for a row that never exists.

>
> And if it does improve performance, why do you want to use the
> esql:limit tag instead of altering the SQL statement?

How can I alter the statement? I can write LIMIT 5, but the code will
rewrite it to LIMIT 6! This is the point. Sometimes we need to assure that
the code write LIMIT 5 not LIMIT 6.

This is why I suggested to just check if there is the <esql:more-results>
tag. If the tag is there, that means that the programmer is not sure if
there are or not more results.

Please think about this issue.

Best Regards,

Antonio Gallardo.

P.S: My english is very poor, sorry that I can not explain better this issue.



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Torsten Curdt <tc...@dff.st>]

> That's really bad! No way to refactor the schema or the query? Or use
> a differen DBMS? E.g. in INFORMIX you can create an index based on a
> user defined function...

...you were faster ;)
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>]

On 27.Jan.2003 -- 02:49 AM, Antonio Gallardo wrote:
> Niclas Hedhman dijo:
> > On Monday 27 January 2003 16:01, Torsten Curdt wrote:
> >> Niclas Hedhman wrote:
> >> > On Monday 27 January 2003 07:06, Torsten Curdt wrote:
> >> >>>What do the database to try to find the 6th row?
> >> >>>
> >> >>>I think the answer is: scan the rest of the database after finding
> >> the ONLY 5 rows that already exist.
> >> >>
> >> >>No :) ...be sure - it doesn't
> >> >
> >> > Well, that depends on the WHERE clause. For instance;
> >> >
> >> > WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
> >> >
> >> > definately go through every record, whether the fields are indexed
> >> or not.

That's really bad! No way to refactor the schema or the query? Or use
a differen DBMS? E.g. in INFORMIX you can create an index based on a
user defined function...

> I have a table that store the status of some tickets. You always know how
> many status there can be. If you said:
> 
> 1-Open
> 2-Close
> 3-Invalid
> 
> Then if you want to show the history, you will ask for LIMIT 3, but the
> database will try to find the 4th row after finding the only 3 that can
> exist.
> 
> This is why I told this is a performance issue. Not an error.

Again I believe an index would help a lot more. With bad luck your
three rows are spread all over the table and you're going to have a
nearly complete table scan anyways.

And if it does improve performance, why do you want to use the
esql:limit tag instead of altering the SQL statement?

Anyway, since you offered to produce a patch, we should consider it.

My 2¢

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Torsten Curdt dijo:
> <snip/>
>
>> I dont agree. The LIMIT 5+1 is just a internal issue. From the user
>> view. he never knows we was asking 5+1 rows. He never can access the
>> 5+1 row. even if it exists.
>
> That is exactly what I was trying to say ;)
>
> Keep in mind we have user -> esql -> classes -> resultset
>
> Who should fix the +1 issue? esql or the class? And if the class (which
> can be confusing) - how...
>
> ...that's what I gonna put under my pillow tonight ;)

Lets put a good description of the hack into the code. Why we did that?
The best solution can be if there are another JBDC function that support
that. But I dont know if this function exist. Then I discarded this
option. :-(

I think that the helper class must resolve this issue. But it must know
when to hack and when not. Maybe adding a parameter to the function that
tell if we want to know if there are more results or not.

This is again hidden from the user view. The user does not work directly
with the esql helper class or with the internally processing of the
esql.xsl.

For me the solution must be clear for the developers of any of the files
the helper class and/or the esql.xsl

I think we have the 1st milestone here. An agree that this will improve
the database experience.

Now we must agree with the solution. Please wait until the solution is
done before tell if this is ugly ;-).

Best Regards,

Antonio Gallardo.




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Torsten Curdt <tc...@dff.st>]

<snip/>

> I dont agree. The LIMIT 5+1 is just a internal issue. From the user view.
> he never knows we was asking 5+1 rows. He never can access the 5+1 row.
> even if it exists.

That is exactly what I was trying to say ;)

Keep in mind we have user -> esql -> classes -> resultset

Who should fix the +1 issue? esql or the class? And if the class (which 
can be confusing) - how...

...that's what I gonna put under my pillow tonight ;)
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Antonio Gallardo dijo:
> Torsten Curdt dijo:
>>> 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!
>
> I dont agree. The LIMIT 5+1 is just a internal issue. From the user
> view. he never knows we was asking 5+1 rows. He never can access the 5+1
> row. even if it exists.
>
> I agree with you that also can be a change into the "esqlhelper
> class" into the method that retrieve the row and get it to the user.

I also remember that the "hack" to trig the <esql:more-results> tag is
just checking is there is the 5+1 row or not. :-), This is the test than
we need to wrap in a if statement.

Best Regards,

Antonio Gallardo




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Torsten Curdt dijo:
>> 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!

I dont agree. The LIMIT 5+1 is just a internal issue. From the user view.
he never knows we was asking 5+1 rows. He never can access the 5+1 row.
even if it exists.

I agree with you that also the can be a change into the "esqlhelper class"
into the method that retrieve the row and get it to the user.
>
> Give me a day to think about this...
You got it! ;-)
> --
> Torsten
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Torsten Curdt <tc...@dff.st>]

> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Torsten Curdt dijo:
> Sure - the question is only how to integrate this easily since we would
> need to pass the information (more-results or not) from the logicsheet
> into the classes.
>
> And please - no ugly hack like "setXXX"
> --
> Torsten

I think XSL will permit an elegant solution. I think this will need just
to find if exist <esql:more-results> tag. Example: Suppose we have:

<esql:max-rows>5</esql:max-rows>

the the esql.xsl will include code like:

if (exist <esql:more-results>)
   LIMIT 5+1
else
   LIMIT 5

I think this is an elegant solution. What you think?

Best Regards,

Antonio Gallardo.




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Torsten Curdt <tc...@dff.st>]

> Thanks Niclas!

:)

> This is the example I tried to explain:
> 
> I have a table that store the status of some tickets. You always know how
> many status there can be. If you said:
> 
> 1-Open
> 2-Close
> 3-Invalid
> 
> Then if you want to show the history, you will ask for LIMIT 3, but the
> database will try to find the 4th row after finding the only 3 that can
> exist.

Well, this might become a little off-topic...
...but wouldn't it be better to change your db design?

> This is why I told this is a performance issue. Not an error.

Sure - the question is only how to integrate this easily since we would 
need to pass the information (more-results or not) from the logicsheet 
into the classes.

And please - no ugly hack like "setXXX"
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Niclas Hedhman dijo:
> On Monday 27 January 2003 16:01, Torsten Curdt wrote:
>> Niclas Hedhman wrote:
>> > On Monday 27 January 2003 07:06, Torsten Curdt wrote:
>> >>>What do the database to try to find the 6th row?
>> >>>
>> >>>I think the answer is: scan the rest of the database after finding
>> the ONLY 5 rows that already exist.
>> >>
>> >>No :) ...be sure - it doesn't
>> >
>> > Well, that depends on the WHERE clause. For instance;
>> >
>> > WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
>> >
>> > definately go through every record, whether the fields are indexed
>> or not.
>>
>> Aaah - now I got you guys! (sorry for being that slow ;)
>>
>> Antonio, how comes that you always know you have 5 rows? This sounds
>> quite unusual to me...
>
> I can answer part of that;
>
> 1. You have the "count" from somewhere else.
> 2. You know that objects of type X has N attributes, always fixed. 3. I
> have 10,000,000 random records of N types. I want the first one of each
> type.
>
> Sure there are other cases.
>
> Niclas

Thanks Niclas!

This is the example I tried to explain:

I have a table that store the status of some tickets. You always know how
many status there can be. If you said:

1-Open
2-Close
3-Invalid

Then if you want to show the history, you will ask for LIMIT 3, but the
database will try to find the 4th row after finding the only 3 that can
exist.

This is why I told this is a performance issue. Not an error.

Antonio Gallardo
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 27 January 2003 16:01, Torsten Curdt wrote:
> Niclas Hedhman wrote:
> > On Monday 27 January 2003 07:06, Torsten Curdt wrote:
> >>>What do the database to try to find the 6th row?
> >>>
> >>>I think the answer is: scan the rest of the database after finding the
> >>>ONLY 5 rows that already exist.
> >>
> >>No :) ...be sure - it doesn't
> >
> > Well, that depends on the WHERE clause. For instance;
> >
> > WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
> >
> > definately go through every record, whether the fields are indexed or
> > not.
>
> Aaah - now I got you guys! (sorry for being that slow ;)
>
> Antonio, how comes that you always know you have 5 rows? This sounds
> quite unusual to me...

I can answer part of that;

1. You have the "count" from somewhere else.
2. You know that objects of type X has N attributes, always fixed.
3. I have 10,000,000 random records of N types. I want the first one of each 
type.

Sure there are other cases.

Niclas


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Torsten Curdt <tc...@dff.st>]

Niclas Hedhman wrote:
> On Monday 27 January 2003 07:06, Torsten Curdt wrote:
> 
>>>What do the database to try to find the 6th row?
>>>
>>>I think the answer is: scan the rest of the database after finding the
>>>ONLY 5 rows that already exist.
>>
>>No :) ...be sure - it doesn't
> 
> 
> Well, that depends on the WHERE clause. For instance;
> 
> WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
> 
> definately go through every record, whether the fields are indexed or not.

Aaah - now I got you guys! (sorry for being that slow ;)

Antonio, how comes that you always know you have 5 rows? This sounds 
quite unusual to me...
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 27 January 2003 07:06, Torsten Curdt wrote:
> > What do the database to try to find the 6th row?
> >
> > I think the answer is: scan the rest of the database after finding the
> > ONLY 5 rows that already exist.
>
> No :) ...be sure - it doesn't

Well, that depends on the WHERE clause. For instance;

WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;

definately go through every record, whether the fields are indexed or not.



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Torsten Curdt <tc...@dff.st>]

> What do the database to try to find the 6th row?
> 
> I think the answer is: scan the rest of the database after finding the
> ONLY 5 rows that already exist.

No :) ...be sure - it doesn't
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Torsten Curdt dijo:
> Antonio Gallardo wrote:
>> Torsten Curdt dijo:
>>
>>>>WHAT IS WRONG?
>>>>
>>>>In example A all is OK.
>>>>
>>>>In example B we are not using the power of the Database Manager.
>>>>
>>>>WHY?
>>>>
>>>>The LIMIT clause was designed to tell the database engine:
>>>>
>>>>"Let find just X rows", then the database engine when it got the X
>>>> rows stop searching and return the X rows. It improves the response
>>>> time, since does not to continue searching!
>>>>
>>>>Now think in a 10 million row table and YOU KNOW you need only 5
>>>> rows!
>>>
>>>whether 10 million rows or not - the current sollution will only ask
>>> for
>>> 6 - one additional row. Is that the time penalty you are talking
>>> about?
>>
>>
>> Yes, because you already know that there are only 5 rows for every
>> register. Then the database will search the last 6th row that no
>> exist. Forcing to searh in the ENTIRE table.
>
> No - why do you think the database searches the entire table?!?
> ...this is just a restriction on the resultset!
> --
> Torsten

Because in the table with 10 millions are ONLY 5 rows that meet your WHERE
clausule. you know that because this is a design issue.

But setting "LIMIT 6" force the database to search the 6th row that you
know does not exist. Then the question is:

What do the database to try to find the 6th row?

I think the answer is: scan the rest of the database after finding the
ONLY 5 rows that already exist.





---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Torsten Curdt <tc...@dff.st>]

Antonio Gallardo wrote:
> Torsten Curdt dijo:
> 
>>>WHAT IS WRONG?
>>>
>>>In example A all is OK.
>>>
>>>In example B we are not using the power of the Database Manager.
>>>
>>>WHY?
>>>
>>>The LIMIT clause was designed to tell the database engine:
>>>
>>>"Let find just X rows", then the database engine when it got the X
>>>rows stop searching and return the X rows. It improves the response
>>>time, since does not to continue searching!
>>>
>>>Now think in a 10 million row table and YOU KNOW you need only 5 rows!
>>
>>whether 10 million rows or not - the current sollution will only ask for
>> 6 - one additional row. Is that the time penalty you are talking about?
> 
> 
> Yes, because you already know that there are only 5 rows for every
> register. Then the database will search the last 6th row that no exist.
> Forcing to searh in the ENTIRE table.

No - why do you think the database searches the entire table?!?
...this is just a restriction on the resultset!
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Torsten Curdt dijo:
>> WHAT IS WRONG?
>>
>> In example A all is OK.
>>
>> In example B we are not using the power of the Database Manager.
>>
>> WHY?
>>
>> The LIMIT clause was designed to tell the database engine:
>>
>> "Let find just X rows", then the database engine when it got the X
>> rows stop searching and return the X rows. It improves the response
>> time, since does not to continue searching!
>>
>> Now think in a 10 million row table and YOU KNOW you need only 5 rows!
>
> whether 10 million rows or not - the current sollution will only ask for
>  6 - one additional row. Is that the time penalty you are talking about?

Yes, because you already know that there are only 5 rows for every
register. Then the database will search the last 6th row that no exist.
Forcing to searh in the ENTIRE table.

Maybe your 5 rows are at the beginning of the table but the non existent
6th row will force the Database Engine to search for this.

Antonio Gallardo.
> --
> Torsten
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [ESQL] Improvement....

[Torsten Curdt <tc...@dff.st>]

> WHAT IS WRONG?
> 
> In example A all is OK.
> 
> In example B we are not using the power of the Database Manager.
> 
> WHY?
> 
> The LIMIT clause was designed to tell the database engine:
> 
> "Let find just X rows", then the database engine when it got the X rows
> stop searching and return the X rows. It improves the response time, since
> does not to continue searching!
> 
> Now think in a 10 million row table and YOU KNOW you need only 5 rows!

whether 10 million rows or not - the current sollution will only ask for 
6 - one additional row. Is that the time penalty you are talking about?
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org