On Sep 28, 2011, at 1:25 AM, Richard Hipp wrote:
> Hence I ask: have you actually measured the difference?
Please join the BAAG party :)
http://www.battleagainstanyguess.com/
___
sqlite-users mailing list
sqlite-users@sqlite.org
On 28 Sep 2011, at 3:01pm, Tim Streater wrote:
> No, I've done no tests. I'm not concerned that each database be down to its
> smallest possible size, merely that the app have a mechanism that, from time
> to time, compresses certain databases through which most of the apps traffic
> flows
On 28 Sep 2011 at 00:25, Richard Hipp wrote:
> On Tue, Sep 27, 2011 at 7:16 PM, Tim Streater wrote:
>
>> On 27 Sep 2011 at 18:15, Richard Hipp wrote:
>>
>>> On Tue, Sep 27, 2011 at 1:13 PM, Tim Streater
>> wrote:
On Tue, Sep 27, 2011 at 7:16 PM, Tim Streater wrote:
> On 27 Sep 2011 at 18:15, Richard Hipp wrote:
>
> > On Tue, Sep 27, 2011 at 1:13 PM, Tim Streater
> wrote:
> >
> >> The databases that get vacuumed tend to have a fair amount of
On 27 Sep 2011 at 18:15, Richard Hipp wrote:
> On Tue, Sep 27, 2011 at 1:13 PM, Tim Streater wrote:
>
>> The databases that get vacuumed tend to have a fair amount of traffic in
>> and out. So it's good to compress them from time to time.
>
> Really?
On Tue, Sep 27, 2011 at 1:13 PM, Tim Streater wrote:
>
> The databases that get vacuumed tend to have a fair amount of traffic in
> and out. So it's good to compress them from time to time.
>
Really? Have you actually measured this to see if it makes a difference?
What
On 27 Sep 2011 at 12:23, Simon Slavin wrote:
> On 27 Sep 2011, at 10:49am, Tim Streater wrote:
>
>> On 27 Sep 2011 at 00:19, Simon Slavin wrote:
>>
>>> I believe that VACUUM is one of the statements which counts as changing the
>>> schema, because it
On 27 Sep 2011, at 10:49am, Tim Streater wrote:
> On 27 Sep 2011 at 00:19, Simon Slavin wrote:
>
>> I believe that VACUUM is one of the statements which counts as changing the
>> schema, because it does its work by rewriting entire tables and/or indexes.
>> So don't do
On 27 Sep 2011 at 00:19, Simon Slavin wrote:
> On 26 Sep 2011, at 11:32pm, Tim Streater wrote:
>> But, very often the database on which the error occurs is :memory: - and I
>> guess each thread will have its own one of those.
>
> Are you doing concurrent access to your
On 27 Sep 2011 at 00:19, Simon Slavin wrote:
> On 26 Sep 2011, at 11:32pm, Tim Streater wrote:
>
>> For the most part it's going to be SELECT, INSERT, UPDATE, BEGIN, COMMIT.
>> Less often, there's VACUUM. Let me have a look at my logs - OK, when I got
>> the error today,
On 26 Sep 2011, at 11:32pm, Tim Streater wrote:
> For the most part it's going to be SELECT, INSERT, UPDATE, BEGIN, COMMIT.
> Less often, there's VACUUM. Let me have a look at my logs - OK, when I got
> the error today, there was a thread doing a VACUUM on the db which got the
> error (within
On Tue, Sep 27, 2011 at 12:32 AM, Tim Streater wrote:
> But, very often the database on which the error occurs is :memory: - and I
> guess each thread will have its own one of those.
>
Not only each thread, but each reference to ":memory:" within a process is
independent
On 26 Sep 2011 at 22:40, Simon Slavin wrote:
> On 26 Sep 2011, at 10:30pm, Tim Streater wrote:
>> My question now is, if two or more PHP scripts are competing for access to
>> the same database, is "database schema has changed" a possible outcome?
>
> Well, let's see what
On 26 Sep 2011, at 10:30pm, Tim Streater wrote:
> it's quite possible that it can ask apache to run three or four threads more
> or less simultaneously, each of which may want to modify the same set of
> SQLite databases. Each such thread is a PHP script using the PDO interface;
> this is
Thinking some more about the occasional instances of "database schema has
changed" that I experience, I took a look through the amalgamation to see where
this error might be being detected. Reading the code and the comments I'm
reminded of something I keep forgetting: that SQLite has no server.
15 matches
Mail list logo