--- Christian Smith <[EMAIL PROTECTED]> wrote:
> 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.)
Yes that's true. You would safe an fsync() call when
the spill occurred, as the journal file has to be
synced before the database is written to. However
the same amount of journal file would hit the disk
surface in the end anyway, so I'm not sure if that
would help any.
I'm not suggesting using external memory in the pager
cache is a good general strategy.
Dan.
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
