Hi, Thanks for your suggestion.

>The optional backward index ordering requires a corresponding DESC index.

In my case, The table have VARCHAR(250).
And, This column is not critical.

I solved as below. 38% performance up.

CREATE ASC INDEX IDX01 ON Test COMPUTED BY(SUBSTRING(V FROM 1 FOR 40));
CREATE DESC INDEX IDX02 ON Test COMPUTED BY(SUBSTRING(V FROM 1 FOR 40));

--
I retry about maximum index size of V1.5.
The V2.1 is fast than V1.5 in this case :)

>>Size: min - max

V1.5.5
VARCHAR(80): 1.08 - 1.17(s) //UNICODE_FSS 80*3=240


V2.1.0
VARCHAR(80): 0.51 - 0.53(s) //UTF8 80*4=320

--
Regards,
Minoru


Helen Borrie wrote:

>At 06:44 PM 25/05/2008, you wrote:
>>Hi,
>>
>>I have INDEX performance problem with FB superserver V2.1 on WinXP.
>>
>>I'm using the IBObjects ordering-change mechenism.
>>The foward INDEX ordering is fast, but backward INDEX ordering is slow.
>
>The optional backward index ordering requires a corresponding DESC index.
>
>
>>This problem suddenly happened between 160 and 170 VARCHAR size of UTF8
>>Charcter set.
>>I get the following result in backward INDEX ordering test case.
>>
>>Size: min - max
>>VARCHAR(100): 0.51 - 0.60(s)
>>VARCHAR(150): 0.78 - 0.84(s)
>>VARCHAR(160): 0.79 - 0.86(s)
>>VARCHAR(170): 3.51 - 3.59(s)
>>VARCHAR(200): 4.30 - 5.51(s)
>>VARCHAR(250): 6.25 - 6.44(s)
>>
>>Is this a performance limit of V2.1?
>>Please any suggestion.
>>
>>
>>Firebird.conf settings:
>>
>>- DefaultDbCachePages = 16384
>>- TempBlockSize = 3200000 (or 6400000)
>>
>>Test sequences:
>>
>>1. Creation table and index
>>
>>CREATE TABLE Test (
>>I INTEGER NOT NULL
>>, V VARCHAR(nnn) CHARACTER SET UTF8
>>, CONSTRAINT TS1PK PRIMARY KEY (I));
>>
>>CREATE INDEX IDX01 ON Test(I);
>
>also
>CREATE DESC INDEX IDX02 ON Test(I);
>
>There has been no change, by the way. Firebird never could use an ASC
>index to perform a DESC sort - and it still can't. Likewise, in IBO,
>providing both ascending and descending sort orders to your ordering items
>is pointless if only the ASC index exists.
>
>./heLen