Subject Re: commit after insert is very slow
Author emb_blaster
> > > yes i know, and what you do with order by ? when you do a query, with index to choose to use in the plan ? the index on the order by or the index on the filter? to know that you must know BEFORE to do the query the amount of row the filter will return to you !
> >
> > So you are telling that you ALWAYS choose the index with a "PLAN" statment and never let the FB engine do it for you?
> >
> OFF COURSE (sorry if i say it a little loudly) ... if i leave firebird choose himself the plan i can go in vacancy before to see the result of the query :(

it's OK... I thougth... o__O

> but i can not complain to much on the optimizer on this point because how to know if it better to read the rows in the order of the order by clause and manually filter them or to read it in the filter order via the index and mannually order by them after... for that you will need to know the number of row returned by the filter BEFORE executing it and the optimizer don't have (yet) such tool

but I think that was what SET (and allmost people here) telled to you should try: Put indexes Asc/Desc in columns and not use all this compoud indexes, then let the engine do the job of select the plan. True that i'm not good in the internals, neither I had your database in my hands, but I stated that updated Index statistcs and others internals help firebird choose almost flawlessly the indexes.

ohh yeahh I agree with you: if I should define the plan before, ME (you, we...) need that compound. But we are not FB... :D

sorry if I said something wrong ;)
I'm not an expert, but I will try to reach there :O

kind regards,