From: | Ofer Israeli <oferi(at)checkpoint(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Cc: | Netta Kabala <nettak(at)checkpoint(dot)com>, Olga Vingurt <olgavi(at)checkpoint(dot)com> |
Subject: | Re: Insertions slower than Updates? |
Date: | 2012-02-20 20:16:39 |
Message-ID: | 217DDBC2BB1E394CA9E7446337CBDEF20102C05A6A44@il-ex01.ad.checkpoint.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Kevin Grittner wrote:
> Ofer Israeli <oferi(at)checkpoint(dot)com> wrote:
>> Kevin Grittner wrote:
>>> Ofer Israeli <oferi(at)checkpoint(dot)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?
>
> Gut feel, 40% does seem high for just that; but HOT updates could
> 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.
Most, if not all of our UPDATEs, involve updating an indexed column, so HOT updates are actually not performed at all :(
From | Date | Subject | |
---|---|---|---|
Next Message | Alessandro Gagliardi | 2012-02-20 21:14:37 | Re: Why so slow? |
Previous Message | Ofer Israeli | 2012-02-20 20:16:16 | Re: Insertions slower than Updates? |