On Wed, 16 Jun 2004, Daniel K wrote:
>--- [EMAIL PROTECTED] wrote:
>>
>> > http://www.sqlite.org/lockingv3.html
>>
>> My thoughts are listed as they come to me.
>>
>> Thought 1:
>>
>> Section 5.0, entitled "Writing to a database file":
>> After the in-memory cache initially spills to disk
>> the exclusive lock must be maintained because the
>> database file is changed. One way to avoid this....
>
>Would you get the same effect if you had a infinitely
>large pager-cache? i.e. if the cache was never spilled
>until the transaction is committed.
>
>If so, then it might be better to figure out how the
>pager cache itself could use secondary storage once
>it reached a configured size. This wouldn't be a file
>format change.
There would be a certain performance hit in this case, as data spilled
would have to be written to disk twice (once on the spill, once on the
commit.) To make matters worse, spilled data could potentially have to be
re-read from the spill file, making a spilled page cause upto 3 disk IOs.
The problem would be compounded by the fact that spilled pages are likely
to be caused by large transactions, which are also more likely to cause
spill data to be purged from the OS cache. So we're talking mucho
performance hit in worst case scenarios.
Spilling directly to the database file may hold up readers, but would be
much more performant.
There was much discussion on how to avoid these problems using version
trees, shadow paging, and probably other solutions. The solution DRH is
implementing is likely to give good concurrency in most cases (small to
medium updates) and no worse than current worst case performance for large
updates. Conversely, a spill file would have much worse than current worst
case performance.
>
>Dan.
>
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
