Subject | Re: [ib-support] PLAN |
---|---|
Author | Svein Erling Tysvær |
Post date | 2001-05-10T08:15:31Z |
Hi Nico,
non-indexed field, basically saying that it has to sort the records after
getting the result set. If the result set is small (which it ought to be),
it doesn't affect performance very much at all. In fact, it may be better
than a PLAN JOIN (<tablename> ORDER ...) which will use the index to order
by rather than an index suitable for your WHERE clause (a bad idea, I
think). PLAN JOIN is something you ought to pay a lot closer attention to.
In general, I find it preferrable if the plan uses one index for each table
involved. I guess it could be useful with a few more occationally if the
indexes aren't very restictive, but mostly my queries slow down if using
too many indexes for each table.
HTAY? (Hope this answers your question),
Set
>I've used the IB_WISQL to check the plan of my queries. I saw twodifferent
>things : a PLAN SORT (...) and a PLAN JOIN (...). What is the differencePLAN SORT will encapsulate the rest of your plan if you order by a
>between the 2 ? What about performance ?
non-indexed field, basically saying that it has to sort the records after
getting the result set. If the result set is small (which it ought to be),
it doesn't affect performance very much at all. In fact, it may be better
than a PLAN JOIN (<tablename> ORDER ...) which will use the index to order
by rather than an index suitable for your WHERE clause (a bad idea, I
think). PLAN JOIN is something you ought to pay a lot closer attention to.
In general, I find it preferrable if the plan uses one index for each table
involved. I guess it could be useful with a few more occationally if the
indexes aren't very restictive, but mostly my queries slow down if using
too many indexes for each table.
HTAY? (Hope this answers your question),
Set