Subject | Re: function TOP n FROM... was (Porting from...) |
---|---|
Author | johnlim@natsoft.com.my |
Post date | 2000-06-27T14:05:56Z |
The reason why I asked about TOP N in the first place is that I use a
3rd party DLL that uses TOP 1 to check if a database table is empty.
This vendor prefers to do a TOP 1 rather than COUNT(*) because some
databases do a full table scan to count the records. TOP 1
<i>hopefully</i> prevents this.
-- John
3rd party DLL that uses TOP 1 to check if a database table is empty.
This vendor prefers to do a TOP 1 rather than COUNT(*) because some
databases do a full table scan to count the records. TOP 1
<i>hopefully</i> prevents this.
-- John
--- In IBDI@egroups.com, Ann Harrison <harrison@n...> wrote:
>
> >
> >TOP isn't standard SQL and it's not a very sensible kind of thing
to ask of
> >a Client/Server database, given that the data isn't stored in any
physical
> >order. I'd be surprised if got anywhere near the top of anyone's
list of
> >"must-haves" for InterBase.
>
> There is one place where TOP<n> would be useful. Currently, an
order
> by clause causes InterBase to retrieve and sort the result set,
unless
> the order by terms match an index exactly and the query is simple
> (single table?). In that restricted case, InterBase retrieves the
> rows in index order. You probably think that index order would be
> faster than sorting, but you would be wrong, in general. The one
case
> where walking in index order is reliably faster is when you want
only
> the TOP<n> rows. So TOP could be a nice hint to the optimizer.
>
> Ann