Subject | Re: LIMIT record in SELECT query gets slow |
---|---|
Author | jasperelzinga |
Post date | 2005-06-30T11:58:15Z |
Thanks for your reaction.
I have been thinking about it, and i think firebird shouldn't have to
run the entire query if I make a index on the same field as where i'm
ordering by. Using the index, firebird should be able to pick the
[skipped] number without having to run any query, and then select the
amount of records i want.
I have tried this and it doesn't work. But maybe it's possible with a
PLAN clause? I can't find much documentation about using PLAN. Do
you/anyone know more about this?
Jasper
I have been thinking about it, and i think firebird shouldn't have to
run the entire query if I make a index on the same field as where i'm
ordering by. Using the index, firebird should be able to pick the
[skipped] number without having to run any query, and then select the
amount of records i want.
I have tried this and it doesn't work. But maybe it's possible with a
PLAN clause? I can't find much documentation about using PLAN. Do
you/anyone know more about this?
Jasper
--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...> wrote:
> Hi Jasper,
>
> You got it in one.
>
> How else should the first / skip work. It has to run your entire query,
> it just doesn't return the first [skipped] records.
>
> so
>
> Select First 50 skip 1000000 *
> from table 1
> join table 2 .....
>
> is going to take an awful long time.
>
> You will see some improvement though because the over-the-wire traffic
> is going to be restricted to 50 records, but your prepare and execution
> time will probably be identical.
>
> I can not confirm this, but I believe it stops the execution once it
> has got its 50, so that is why it performs better "near the top". You
> may be able to reverse the statement a bit (using a order by ... desc)
> and providing you have a descending index to back it up it should run
> pretty quick.
>
> Adam