Svein Erling Tysvær skriver:

>
> Does the 'INSERT INTO' take equally long time if you use a unique (or at
> least selective) value in all the indexed fields which have over 100
> million max duplicates?

Well, I tried to insert a record with null in all nullable columns,
which should "hit" the long duplicate chains of all indexes, so should
be slow, right? It wasn't. In FlameRobin, after having closed all,
including the FB service and then restarted FB service, FlameRobin,
connect from FR, insert as the first thing. Cache should be empty at
this point.

So, I guess I'll have to check exactly what statement from my
application causes this long execution time. I'm unable to reproduce it
from FlameRobin, it seems.

I'll keep you idea in mind in case I find time to investigate this
further. It's part of a once-only batch import, so if it doesn't happen
anywhere else, there's probably no point in digging.

Anyway, I thank Ann and SET for trying to shed some light...

Kjell

> I just thought this could be a quick way to check whether this was the
> reason, unfortunately I've no idea how to improve the situation if it is
> (well, you could of course try to add the primary key to the end of the
> index as everybody did a few versions ago)...

--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64