On Wed, May 14, 2008 at 3:40 PM, Jay A. Kreibich <[EMAIL PROTECTED]> wrote:
>
>>
>> WORKAROUNDS:
>>
>> Or, brute force: Copy the file locally, do your stuff, copy it back.
>>
> Looks like the brute force solution is the only answer here.
(Translated automatically from the Spanish original)
..
On Wed, May 14, 2008 at 3:40 PM, Jay A. Kreibich <[EMAIL PROTECTED]> wrote:
>
>
> WORKAROUNDS:
>
> Set SQLites page size to be much larger (PRAGMA page_size).
>Makes SQLite deal with bigger chunks of data, reducing the overhead
>percentage. You'll very likely need to turn this up pretty
On Wed, May 14, 2008 at 02:40:28PM -0600, Peter K. Stys scratched on the wall:
> On Wed, May 14, 2008 at 2:09 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> > Performance on a remote volume is about 20x slower because the raw I/O
> > capability of a network disk drive is about about 1/20th of a
> You may see some performance increase by setting pragma page_size to a
> larger value so that SQLite transfers fewer, but larger, blocks across
> the network. I would try benchmark tests with page sizes of 8K and 32K
> to see if there is a substantial difference.
Good point Dennis, though you
> I would disagree with this, unless I misunderstand. File copies (from the
> Finder under OS X) to/from our Xserve run at about 50 MBytes/s or about 50%
> of theoretical max on our Gbit LAN, whereas reading the records from the
> same file via SQLite is 20-25x slower (—2MB/sec at best, terrible
>
Peter K. Stys wrote:
>
> I would disagree with this, unless I misunderstand. File copies (from the
> Finder under OS X) to/from our Xserve run at about 50 MBytes/s or about 50%
> of theoretical max on our Gbit LAN, whereas reading the records from the
> same file via SQLite is 20-25x slower (≈2MB
On Wed, May 14, 2008 at 2:09 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
>
> On May 14, 2008, at 3:58 PM, Peter K. Stys wrote:
>
> > I'm curious, when you say performance enhancements, does that include
> > improved R/W performance to/from remote volumes on OS X, which
> > presently
> > suffer
On May 14, 2008, at 3:58 PM, Peter K. Stys wrote:
> I'm curious, when you say performance enhancements, does that include
> improved R/W performance to/from remote volumes on OS X, which
> presently
> suffer serious (20-fold) speed issues. I had a recent post on this.
> If not, will 3.6.0 addr
I'm curious, when you say performance enhancements, does that include
improved R/W performance to/from remote volumes on OS X, which presently
suffer serious (20-fold) speed issues. I had a recent post on this.
If not, will 3.6.0 address this?
Thanks,
Peter.
On Wed, May 14, 2008 at 11:17 AM, D.
On May 14, 2008, at 2:14 PM, Petite Abeille wrote:
>
> On May 14, 2008, at 8:10 PM, D. Richard Hipp wrote:
>
>> Works for me. Did you compile the shell yourself or use the prebuilt
>> binary?
>
> I did compile it myself. Any additional configuration(s) one should
> take care of to enable this pr
On May 14, 2008, at 8:10 PM, D. Richard Hipp wrote:
>
> Works for me. Did you compile the shell yourself or use the prebuilt
> binary?
Ooops... never mind... the shell works fine... I was using
sqlite3_prepare and my application was linked against a different
version of the lib...
Everythi
On May 14, 2008, at 8:10 PM, D. Richard Hipp wrote:
> Works for me. Did you compile the shell yourself or use the prebuilt
> binary?
I did compile it myself. Any additional configuration(s) one should
take care of to enable this pragma?
___
sqlite-
On May 14, 2008, at 1:59 PM, Petite Abeille wrote:
> Hello,
>
> On May 14, 2008, at 7:17 PM, D. Richard Hipp wrote:
>
>> There is also a new *experimental* PRAGMA called "journal_mode"
>> which can provide performance improvements under some circumstances.
>
> I'm trying the new journal_mode prag
Hello,
On May 14, 2008, at 7:17 PM, D. Richard Hipp wrote:
> There is also a new *experimental* PRAGMA called "journal_mode"
> which can provide performance improvements under some circumstances.
I'm trying the new journal_mode pragma:
% uname -v
Darwin Kernel Version 9.2.2; root:xnu-1228.4
14 matches
Mail list logo
