Re: [sqlite] performance of select in transactions

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

Re: [sqlite] performance of select in transactions

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). > >

Re: [sqlite] performance of select in transactions

> 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

Re: [sqlite] performance of select in transactions

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

Re: [sqlite] performance of select in transactions

> 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