> AWH> No. Defining the right set of indexes is the best way to
> AWH> improve speed.
>While on subject, I'm experiencing an inexpected slow response from a
>SP that does several DELETE FROM xx WHERE PK>=:x in row on a set of
>tables. There are no triggers/secondary keys involved. The sweep
>interval should be 0, but since I was working on a freshly restored db
>sweep shouldn't be the case. When I tried doing it's work by hand,
>thus executing 10 DELETEs, it took a reasonable amount of time to
>complete.
>
>Is there *any* other consideration to do in such situation?

Well, Lele, it is not quite another consideration, but what makes deletes
slow are things like indexes with low selectivity. E.g. if you have an index
on "Country" and 90% of your customers are from Italy, a delete of an
Italian will be dead slow even if you use DELETE FROM xx WHERE PK>=:x. The
recommended solution is normally to add the PK to the index which makes the
index unique and your deletes faster. But there is no need to overdo this,
i.e. an index on address will be sufficient, even though two customers could
live in the same house.

HTH,
Set