On 2 Oct 2009, at 8:40pm, Mike Shal wrote:
> Ahh, ok - that makes sense. Does this locking overhead not occur on
> other platforms (I've only tried linux -- gentoo and ubuntu), or if
> sqlite is built differently?
It's to do with how the platform (OS and hard disk format) support
file locking.
On 10/2/09, Pavel Ivanov wrote:
> > It seems a bit disingenuous to claim
> > there will be no performance gain by putting selects in a transaction,
> > when sqlite clearly does less work with the transaction (in the form
> > of not getting the read lock multiple times).
>
>
> It's pretty ingenu
> It seems a bit disingenuous to claim
> there will be no performance gain by putting selects in a transaction,
> when sqlite clearly does less work with the transaction (in the form
> of not getting the read lock multiple times).
It's pretty ingenuous in fact to silently assume that nobody wants
On 10/2/09, Pavel Ivanov wrote:
> > Does anybody know why just adding the begin/commit here improves
> > performance? If I have to do a large number of selects like this in my
> > application, should I always wrap it in a transaction?
>
>
> This looks like some overhead of your file system. When
> Does anybody know why just adding the begin/commit here improves
> performance? If I have to do a large number of selects like this in my
> application, should I always wrap it in a transaction?
This looks like some overhead of your file system. When you don't put
begin/commit around selects the
It seems to be common knowledge that running selects inside a
transaction should offer no performance benefit (for example, this
thread has a number of replies to that effect:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg41699.html).
However, I noticed a curious behavior in my application
6 matches
Mail list logo
