Note sure. Will get back on this as soon as I have played a bit with the
analyzer utility!
What I meant was My own estimated x bytes/row :)
x + ID + ~20 characters should make some ~32 bytes :)
Date: Wed, 23 Feb 2011 10:58:00 -0800
From: fle...@fletchowns.net
To: sqlite-users@sqlite.org
this) is there any reason not to use them?
Greg
On Mon, Feb 21, 2011 at 4:37 PM, Stephen Oberholtzer
oliverkloz...@gmail.com wrote:
On Mon, Feb 21, 2011 at 11:35 AM, Jim Wilcoxson pri...@gmail.com wrote:
On Mon, Feb 21, 2011 at 11:05 AM, Sven L larvpo...@hotmail.se wrote:
Thank
Does this trick work on the primary key? If not, why?
From: max.vla...@gmail.com
Date: Wed, 23 Feb 2011 16:09:04 +0300
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] COUNT() extremely slow first time!
On Tue, Feb 22, 2011 at 9:59 PM, Greg Barker fle...@fletchowns.net wrote:
I'm
Thanks for pointing this out!
In my case I have spent much time on normalizing my tables, so the row size
should be constant in most cases. I do wonder though, what if the row size is
32 bytes? Or is there a minimum?
For instance, I have many lookup tables with ID+text (usually around 20
Make sure your antivirus is turned off when you run your vacuum test.
It's a long-shot, but I've seen some AVs lock files etc...
Date: Wed, 23 Feb 2011 10:14:15 -0600
From: j...@kreibi.ch
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Problem with VACUUM feature
On Wed, Feb 23, 2011
Can't seem to find a setting to control how the database file grows when full.
Is there such a setting?
It looks like the file increases by some 100 kB when it is full. I want to
change this to around 10 MB (or even more) to avoid file fragmentation.
Any ideas?
Thanks
.
Pavel
On Tue, Feb 22, 2011 at 9:13 AM, Sven L larvpo...@hotmail.se wrote:
Thanks a lot! :D
What do you think of setting the chunk size to approximately 10% of the
database file size? Or is it better to use a constant?
From: paiva...@gmail.com
Date: Tue, 22 Feb 2011 08:30:54
SQLite 3.7.5.
I have a table (13 columns with 1 primary key, 1 index on a date column, 1
UNIQUE-constraint on two columns).
I insert ~130 rows, 1000 at a time (transaction-wise).
I close the database, reopen it and immediately perform a COUNT-operation:
SELECT COUNT(ItemID) FROM Items;
for your help!
From: slav...@bigfraud.org
Date: Mon, 21 Feb 2011 14:24:50 +
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] COUNT() extremely slow first time!
On 21 Feb 2011, at 2:23pm, Sven L wrote:
SELECT COUNT(ItemID) FROM Items;
This takes around 40 seconds the first time
have little control over it.
That may be true, but it's useful to understand how it can affect
performance. I think you are seeing this first hand.
Jim
--
HashBackup: easy onsite and offsite Unix backup
http://www.hashbackup.com
On Mon, Feb 21, 2011 at 9:37 AM, Sven L larvpo
...@bigfraud.org
Date: Mon, 21 Feb 2011 16:56:01 +
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] COUNT() extremely slow first time!
On 21 Feb 2011, at 4:35pm, Jim Wilcoxson wrote:
On Mon, Feb 21, 2011 at 11:05 AM, Sven L larvpo...@hotmail.se wrote:
Thank you for your detailed explanation
sqlite3* db = NULL;
if (sqlite3_open_v2(path, db, SQLITE_OPEN_READWRITE, NULL) == SQLITE_CANTOPEN)
{
// Ok, database does not exist. Still, db != NULL...?
ASSERT(db != NULL);
}
Database cannot be opened, but we get an open handle to it... Please explain!
Thanks.
Lol... we just had a long discussion about sqlite_stat2 and ANALYZE command.
I removed these from my code, since the command should not be used except for
rare cases :P
Should I re-add my ANALYZE-code and ask my original question again? Confused :P
From: d...@sqlite.org
Date: Sat, 12 Feb
the problem I
encountered had something to do with those tables.)
Regards
From: slav...@bigfraud.org
Date: Tue, 8 Feb 2011 16:53:52 +
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Regarding Manual Control Of Query Plans
On 8 Feb 2011, at 4:22pm, Sven L wrote:
Thank you very much
: [sqlite] Regarding Manual Control Of Query Plans
On 7 Feb 2011, at 9:37pm, Sven L wrote:
Thanks for input. So you're saying that creating the tables manually is not
the same as issuing the ANALYZE command?
You have no idea what the ANALYZE command does because it's not documented
to be as tolerant as possible. Perhaps it's a better idea to simply
crave decent SQL!
From: slav...@bigfraud.org
Date: Tue, 8 Feb 2011 15:16:58 +
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Regarding Manual Control Of Query Plans
On 8 Feb 2011, at 2:39pm, Sven L wrote
I've discovered that the ANALYZE command is extremely slow on my large
databases. I read the documentation and it says that the command should be
issued when the schema is changed a lot. Hmm, when exactly could that be?
Currently, I issue the command every time I have inserted ~1000 rows in my
, Sven L wrote:
I've discovered that the ANALYZE command is extremely slow on my large
databases. I read the documentation and it says that the command should be
issued when the schema is changed a lot. Hmm, when exactly could that be?
Currently, I issue the command every time I have
produces nothing even though the table does contain several
rows: .dump sqlite_stat2
Thanks
From: slav...@bigfraud.org
Date: Mon, 7 Feb 2011 16:44:00 +
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Regarding Manual Control Of Query Plans
On 7 Feb 2011, at 4:38pm, Sven L wrote:
So
;
BEGIN TRANSACTION;
COMMIT;
-
A bug?
From: d...@sqlite.org
Date: Mon, 7 Feb 2011 14:42:06 -0500
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Regarding Manual Control Of Query Plans
On Mon, Feb 7, 2011 at 1:48 PM, Sven L
20 matches
Mail list logo
