Re: full table scan performance

What Rod says is true. To test this, click in the results window of SQL Worksheet, then go to the EDIT menu and click on CLEAR ALL. This will wipe out the results buffer of the
>8K rows that were selected.

Michael

Rod Stewart wrote:
>
> SQL worksheet maintains a mighty big buffer at times. If you are selecting
> that many rows It is going to get slower each time as the buffer gets bigger
> and so on. Taking a trace and analyzing the statistics as suggested by
> Olivier is the way to go.
>
> dean_at_gfsmortgage.com wrote in message <6rco9n$22p$1_at_nnrp1.dejanews.com>...
> >I stumbled across something I've never encountered and was wondering if
> anyone
> >had any suggestions. I'm sure it's a parameter matter, but I can't see it.
> >
> >While playing around with optimizing full table scans I noticed that if I
> did
> >a
> >
> > select * from table_1
> >
> >from SQL Worksheet (locally on the server)
> >
> >It took 40 seconds to get all 8302 rows. If I hit F5 to execute it again,
> it
> >took 1:20, hit F5 again and it took about 1:45. It seems to continue to
> get
> >worse after that.
> >
> >I am the only one logged onto the server (an NT 4.0 SP3 Dell Poweredge
> 2300)
> >and I only run the one query.
> >
> >If I close SQL Worksheet and reopen it, the same process continues (:40,
> 1:20,
> >1:45, etc.) This happens even if I cache the table via hints.
> >
> >Anyone know what I've screwed up?
> >
> >-Dean
> >
> >-----== Posted via Deja News, The Leader in Internet Discussion ==-----
> >http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Received on Wed Aug 19 1998 - 11:26:51 CDT