> > On Thu, Dec 11, 2014 at 10:58 AM, Paul wrote:
> >
> > >
> > > I have yet to try and test if dropping stat tables worth the effort.
> > >
> >
> > Most of the work is involved in loading sqlite_stat4. On the other hand,
> > most of the benefit comes from sqlite_stat1. So consider compiling wit
>
> On 2014/12/11 17:58, Paul wrote:
> >
> >> On 2014/12/11 13:51, Paul wrote:
> >> I have yet to try and test if dropping stat tables worth the effort. Some
> >> databases in fact can grow pretty big, up to few
> >> hundred of megabytes//
>
> In that case maybe keep the Stat1 tables and
On 2014/12/11 17:58, Paul wrote:
On 2014/12/11 13:51, Paul wrote:
I have yet to try and test if dropping stat tables worth the effort. Some databases in fact can grow pretty big, up to few
hundred of megabytes//
In that case maybe keep the Stat1 tables and there is also the option of u
> On Thu, Dec 11, 2014 at 10:58 AM, Paul wrote:
>
> >
> > I have yet to try and test if dropping stat tables worth the effort.
> >
>
> Most of the work is involved in loading sqlite_stat4. On the other hand,
> most of the benefit comes from sqlite_stat1. So consider compiling without
> SQLITE_EN
On Thu, Dec 11, 2014 at 10:58 AM, Paul wrote:
>
> I have yet to try and test if dropping stat tables worth the effort.
>
Most of the work is involved in loading sqlite_stat4. On the other hand,
most of the benefit comes from sqlite_stat1. So consider compiling without
SQLITE_ENABLE_STAT4. You
Hi Ryan, thanks for reply.
>
> On 2014/12/11 13:51, Paul wrote:
> > In my specific case I need to open database as fast as possible.
> > Usual working cycle: open -> select small data set -> close.
> > It is irrelevant how much time it takes to open database when
> > data is being added or update
On 2014/12/11 13:51, Paul wrote:
In my specific case I need to open database as fast as possible.
Usual working cycle: open -> select small data set -> close.
It is irrelevant how much time it takes to open database when
data is being added or updated, since it happens not too often.
/Snipped
PART 2
INSERT INTO sqlite_stat4 VALUES('LLL','LLL_idx','676 1 1','0 330 330','0 327
330',X'0408040253be558403a9');
INSERT INTO sqlite_stat4 VALUES('LLL','LLL_idx','676 1 1','0 661 661','0 655
661',X'04080402547bf6900b13');
INSERT INTO sqlite_stat4 VALUES('LLL','LLL_idx','1093 5 1','676 720 723',
Hello, Richard, thanks for quick reply.
Unfortunately, no, there is no way. On our servers we have big number
of entities that represent client data. Data for different clients can
be read at any given point of time by clients and by a bunch of daemons
responsible for different maintenance jobs.
Hello, Simon.
>
> On 11 Dec 2014, at 11:51am, Paul wrote:
>
> > I understand, that having them is a must for a decent performance.
> > In my specific case I have millions of individual database files.
> > This is one, among other reasons that I can't keep them open all the time.
> > Just too
On Thu, Dec 11, 2014 at 6:51 AM, Paul wrote:
>
> Hello.
>
> In my specific case I need to open database as fast as possible.
> Usual working cycle: open -> select small data set -> close.
> It is irrelevant how much time it takes to open database when
> data is being added or updated, since it ha
On 11 Dec 2014, at 11:51am, Paul wrote:
> I understand, that having them is a must for a decent performance.
> In my specific case I have millions of individual database files.
> This is one, among other reasons that I can't keep them open all the time.
> Just too many of them. These database
Hello.
In my specific case I need to open database as fast as possible.
Usual working cycle: open -> select small data set -> close.
It is irrelevant how much time it takes to open database when
data is being added or updated, since it happens not too often.
But for selects it's a different story
13 matches
Mail list logo
