Subject | Re: [firebird-support] Re: commit after insert is very slow |
---|---|
Author | André Knappstein, Controlling |
Post date | 2010-03-03T15:02:17Z |
SET> As for 'ORDER BY', that is generally not the point of indexes.
SET> JOIN and WHERE would normally reduce the result set considerably
SET> and then ORDER BY could normally be done quicker without using any index at all.
Unfortunately, that depends on the tools used to create the client
application. Some old legacy tools demand an index for each "order by"
or "where" and if it does not exist they automatically do create
read-only datasets (not a bad thing, generally, but
legacy-tool-programmers oftenly seem to think it's normal to keep a
read/write set open for hours....)
One of the first things I keep telling those who I help migrating away
from DBF/BDE is the same that you just told: throw away all indexes
but the primary key and re-add them only after double checking the
efficiency.
---
SET> JOIN and WHERE would normally reduce the result set considerably
SET> and then ORDER BY could normally be done quicker without using any index at all.
Unfortunately, that depends on the tools used to create the client
application. Some old legacy tools demand an index for each "order by"
or "where" and if it does not exist they automatically do create
read-only datasets (not a bad thing, generally, but
legacy-tool-programmers oftenly seem to think it's normal to keep a
read/write set open for hours....)
One of the first things I keep telling those who I help migrating away
from DBF/BDE is the same that you just told: throw away all indexes
but the primary key and re-add them only after double checking the
efficiency.
---