thanks for the explanation.. now... i looked at the indexes and found that the biggest one that must be reduced and, consequently, will make the procedure quicker.

TABLE:tbrelshape
BRUSHID
SHAPE
WIDTH
LENGTH
THICKRADIUS

Primary key(brushid,shape)


the index has a selectivity of 0.083333 and the others 20 indexes used at the procedure have value lower than 0.005...

the index is the shape field from the table which is a foreign key to a table TBSHAPE will all possible shapes.

the population of the table is as follow (brushid is always different):

1 = CON
145 = CYL
551 = PAIR
78373 = SINGLE
20207 = SPLIT
16 = TRIPLE
256 = TSPLIT
1 = WEDGE



well, running the procedure for shape TRIPLE, for example, it is really quick while for SINGLE, the problem i am talking about appears....

i will thanks for any idea of how i should modify the indexes in such order to get a procedure always fast as possible Or how i could organize this little data in such way to get a procedure always fast...







---
Luís Carlos Dill Junges ©

"A realidade de cada lugar e de cada época é uma alucinação coletiva."
Bloom, Howard



________________________________
De: Dimitry Sibiryakov <sd@...>
Para: firebird-support@yahoogroups.com
Enviadas: Terça-feira, 5 de Maio de 2009 14:28:21
Assunto: Re: [firebird-support] Optimization - Select Query

> The problem is that after some time it requires the 8~10 seconds again. It seems that after some time the optimization table (or whatever is) is deleted.

It is not "optimization table" but "data cache". To make you query to
be always fast you must analyse it's plan and, perhaps, change the query
or data structure. May be add needed index or remove unneeded one.

SY, SD.

__________________________________________________
Fale com seus amigos de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

[Non-text portions of this message have been removed]