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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
