Slow performance using SELECT *

Slow performance using SELECT *

Post by Russ » Thu, 05 Feb 1998 04:00:00



I've been evaluating RDO in Visual Basic accessing a SQLAnywhere v5.0
database.  I'm getting very odd performance metrics:

select note_id, note_type, note_text from mynotes       12 seconds

select * from mynotes                                   70 seconds.

There are a total of twelve columns in mynotes and none of them are
"large" except note_text.  Any idea what's going on?

-Russ

 
 
 

Slow performance using SELECT *

Post by ke.. » Fri, 06 Feb 1998 04:00:00


Well..

SELECT * will always do table scan..

I guess your table may have non-clustered index on note_id, note_type and note_text.. If this is the case, the optimizer will just scan the index leaf pages to get the result, which can be much faster than table scan.

Hope this help.

Ken

 
 
 

Slow performance using SELECT *

Post by Richard Freedma » Fri, 06 Feb 1998 04:00:00


This should be a non-problem as far as any software that
you are writing. Due to the fact that a column could be
added to the table (as well as the performance problem),
IMHO,  "SELECT *"  should never be used in production code.


> Well..

> SELECT * will always do table scan..

> I guess your table may have non-clustered index on note_id, note_type and note_text.. If this is the case, the optimizer will just scan the index leaf pages to get the result, which can be much faster than table scan.

> Hope this help.

> Ken

 
 
 

Slow performance using SELECT *

Post by Russ » Sat, 07 Feb 1998 04:00:00



> Well..

> SELECT * will always do table scan..

> I guess your table may have non-clustered index on note_id, note_type and note_text.. If this is the case, the optimizer will just scan the index leaf pages to get the result, which can be much faster than table scan.

> Hope this help.

> Ken

I don't think I have any indexes (except pkey definition) on the table.
Would it help if I add an "order by" on some column or explicitly list
all of the columns instead of using "*"?  Thanks.

-Russ

 
 
 

Slow performance using SELECT *

Post by ke.. » Tue, 10 Feb 1998 04:00:00


Yes absolutely.. as a rule of thumb.. you should avoid using SELECT * anyway.. because it force SQL server to return un-necessary data columns back to client application..

Ken

 
 
 

1. UNION SELECT slow performance

I have a set of four SELECT statements that execute very fast individually
(less than 1 second).  But when I UNION them together, it takes over 2
minutes!  Can someone please help!

Thanks, Ryan

2. ServerLoop

3. Locator buffer size to small

4. Slow performance in Select statement

5. Update datacombo

6. GRANT SELECT slow performance

7. Real-time OLAP

8. using commit transacion slows performance

9. Slow performance using a cursor

10. Slow performance using container elements in xsd Schemas

11. Slow performance using Default Result Sets

12. slow performance using insert into