If the updates don't hit indexed columns (so the indexes don't need to be rebuilt), then the update would be very fast.
Inserts would always affect the index causing it to constantly need modifying.
If you're doing a lot of INSERTs in a batch operation, you may want to consider dropping the indexes and recreating at the end.
On Mon, Feb 20, 2012 at 2:29 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
Ofer Israeli <
oferi@checkpoint.com> wrote:
> Kevin Grittner wrote:
>> Ofer Israeli <
oferi@checkpoint.com> wrote:
>>> Anyone have any ideas on why the empty db is giving worse
>>> results??
>>
>> Besides the HOT updates being fast, there is the issue of having
>> space already allocated and ready for the database to use, rather
>> than needing to make calls to the OS to create and extend files
>> as space is needed.
>
> I thought about this direction as well, but on UPDATES, some of
> them will need to ask the OS for more space anyhow at least at the
> beginning of the run, additional pages will be needed. Do you
> expect that the OS level allocations are so expensive as to show
> an ~%40 increase of processing time in average?
easily account for that, especially since you said that the tables
are "heavily indexed". That is, as long as there are enough updates
which don't modify indexed columns.
-Kevin
--
Steve Horn
http://www.stevehorn.ccsteve@stevehorn.cc
http://twitter.com/stevehorn 740-503-2300