It is almost always best to optimize on the WHERE clause, since it (usually)
limits the amount of data being sorted. I believe that the SRDE will try
that first. A better index would be (C3, C1) in this case. With the
Greater-Than in there, it shoots the chance of using a more detailed index.
When optimizing, always think about how you would do it as a Btrieve app
with NO data distribution knowledge. Then, see how you would do it MOST
efficiently, and then taylor your SQL to match that.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: September 16-18: See our web site for details!
"Alex D. Pichkurov" wrote:
Quote:
If I have a table T1 , for example with columns (real T1 have many other
columns) :
C1 int NOT NULL ,
C2 date NOT NULL
C3 char(10) NOT NULL
C4 int NOT NUL
T1 Table populated with 100 K row and 2 indexes:
Index1 (C1)
Index2 (C2,C1,C3,C4)
So, when Executing the query
"Select * From t1 Where C3=4 AND C1>1000 Order BY C2, C1",
Pervasive "Query Plan Viewer" give me a plan:
SCAN (Retrival data) by Index1 -> Filter (Range) - > Filter (Normal) -
Ordered Temp Table.
And I'ts query executing for a 30 min.
WHY NOT TO USE index2 ? And avoid to use temp table ?
--
Alex D. Pichurov |