Re: [sqlite] Reason for random names for the master journal?

[Dan Kennedy]

>> For example, say you have two databases in a transaction - mine.db
>> and yours.db. A crash happens while committing the transaction
>> and the file mine.db-mjMASTER is left in the file-system.
>>
>> Following recovery, if a process tries to read mine.db, the
>> transaction on mine.db will be rolled back. But the master
>> journal file cannot be deleted yet (since the interrupted
>> transaction on yours.db has not yet been reverted).
>>
>> If the process then attaches "ours.db" and then tries to
>> write a multi-file transaction that involves mine.db and
>> ours.db it has a problem - it wants to create and populate
>> mine.db-mjMASTER but it cannot, since that file is still
>> in use.
>>
>> We use the random names to get around this problem.
>> You could probably get away with using "-mjMASTER1",
>> "-mjMASTER2" etc. if you wanted to. See the loop around
>> line 1729 of vdbeaux.c.
>>
 >
> We have 2 databases. We open one and attach the other one to it at the
> very beginning of our single (multi-threaded) database process.
> Subsequently, we starting issuing SQL statements that could affect
> either one or both databases. It seems we could get by with a single
> master-journal filename. Do you agree?

Probably. Sounds Ok in theory.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Virtual Table and the xBestIndex

[Jay A. Kreibich]

On Fri, Feb 25, 2011 at 09:30:00PM -0500, Dariusz Matkowski scratched on the 
wall:

> I am trying to implement a simple virtual table that reads in a file
> with two columns and "::" separator. My question is: is it necessary
> to implement xBestIndex to run a simple where clause queries?

  You must implement a xBestIndex() function, but it does not need to
  do anything other than return SQLITE_OK.  This will result in a full
  table scan for each query, but for something like a flat file (where
  you cannot easily jump to specific records) that's usually not a
  significant limitation.

-j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] long insert statement failing on iPhone

[Mickey Mestel]

hi all,

new to the list.

we are compiling the sqlite.c amalgamation file into our project, as we 
want to encrypt the database, and the sqlite that comes with the iOS sdk does 
not allow for that.

we are developing on iOS 4.2, and to date have tried 3 different 
versions of sqlite.c, all of which have the same effect.

the issue is that when we prepare a statement like:

insert into tablename (foo, foo1, foo2) values (?,?,?)

and that statement is longer that roughly 250 characters, the table 
name and sometimes the column name are getting munged, most often over written 
with one of the column names in the table, or column list in the statement, 
wherever it is getting it from.

i've just started on this problem, so i may not yet have a lot of 
details, but by the time we are in yy_reduce() and calling sqlite3Insert(), the 
corruption has already taken place.  so i'm trying to trace this back and see 
what is going on.

this only happens on the device, not the simulator, unfortunately.  the 
sqlite library that comes with iOS does not exhibit this behavior.

any thoughts or pointers or help?

thanks,

mickm
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Virtual Table and the xBestIndex

[Dariusz Matkowski]

Hi all,
I am trying to implement a simple virtual table that reads in a file with two 
columns and "::" separator. My question is: is it necessary to implement 
xBestIndex to run a simple where clause queries?

Thank you.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Reason for random names for the master journal?

[Drake Wilson]

Quoth Johns Daniel , on 2011-02-25 16:21:54 -0600:
> Thank you very much for this info, Dan! Very useful.
> 
> >From your description, it sounds like this requirement only applies if
> there are 3 or more databases. Is this an issue with 2 databases?

Yes, master journals are needed whenever more than one database is
used.  However:

> We have 2 databases. We open one and attach the other one to it at the
> very beginning of our single (multi-threaded) database process.

If you allocate a master journal name for only that process, and there
is only one instance starting up at a time (ensured externally), and
it always attaches both databases with the same names and in the same
order before doing anything else, it seems like it should be okay; if
there is a hot master journal, then it will be destroyed at startup
time when both databases have their respective journals recovered.

However, I'm not sure how the threading affects this if you have
multiple connections.  It seems like it should still be okay if
they're all using the exact same two databases, since there should not
be a case where they both want to collide on the master journal where
they would not also be colliding on at least one database, but I'm not
confident about that.

I would try it and see what happens, but also be rather cautious about
the design in such cases; it's hard to judge more accurately without
knowing more about the application.

> -- Johns

   ---> Drake Wilson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Reason for random names for the master journal?

[Johns Daniel]

On Fri, Feb 25, 2011 at 12:04 PM, Dan Kennedy  wrote:
> On 02/26/2011 12:30 AM, Johns Daniel wrote:
>> What is the reason was for having random filenames for the SQLite
>> master journal file (like mine.db-mj501CA440, mine.db-mj1C17,
>> mine.db-mj66677495, etc)?
>>
>> Here is the reason for this strange question. We have discovered that
>> the JFFS2 filesystem in Linux is leaking kernel memory each time we
>> open/close/delete a file with a different name! I have not figured out
>> how to fix the leak in JFFS2 yet. I was wondering whether this
>> workaround is safe: Change our SQLite code to always use a fixed
>> filename (like mine.db-mjMASTER).
>
> The problem is that if a crash occurs during a multi-file commit,
> the master journal cannot be removed from the file-system until
> the transactions have been rolled back for all database files.
> And this doesn't happen until the first time each of them is
> read.
>
> For example, say you have two databases in a transaction - mine.db
> and yours.db. A crash happens while committing the transaction
> and the file mine.db-mjMASTER is left in the file-system.
>
> Following recovery, if a process tries to read mine.db, the
> transaction on mine.db will be rolled back. But the master
> journal file cannot be deleted yet (since the interrupted
> transaction on yours.db has not yet been reverted).
>
> If the process then attaches "ours.db" and then tries to
> write a multi-file transaction that involves mine.db and
> ours.db it has a problem - it wants to create and populate
> mine.db-mjMASTER but it cannot, since that file is still
> in use.
>
> We use the random names to get around this problem.
> You could probably get away with using "-mjMASTER1",
> "-mjMASTER2" etc. if you wanted to. See the loop around
> line 1729 of vdbeaux.c.
>

Thank you very much for this info, Dan! Very useful.

>From your description, it sounds like this requirement only applies if
there are 3 or more databases. Is this an issue with 2 databases?

We have 2 databases. We open one and attach the other one to it at the
very beginning of our single (multi-threaded) database process.
Subsequently, we starting issuing SQL statements that could affect
either one or both databases. It seems we could get by with a single
master-journal filename. Do you agree?

-- Johns
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] BUG: types3.test

[Noah Hart]

this test in types3 says that the type is ""

do_test types3-2.5 {
  set V [db one {SELECT '1234567890123456.0'}]
  tcl_variable_type V
} {}

however when I try it from the command line i get text

SQLite version 3.7.5
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> SELECT '1234567890123456.0', typeof('1234567890123456.0');
1234567890123456.0|text

I think that the test is wrong and tcl should be expecting {string}

Regards,

Noah Hart
-- 
View this message in context: 
http://old.nabble.com/BUG%3A-types3.test-tp31016794p31016794.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Reason for random names for the master journal?

[Dan Kennedy]

On 02/26/2011 12:30 AM, Johns Daniel wrote:
> What is the reason was for having random filenames for the SQLite
> master journal file (like mine.db-mj501CA440, mine.db-mj1C17,
> mine.db-mj66677495, etc)?
>
> Here is the reason for this strange question. We have discovered that
> the JFFS2 filesystem in Linux is leaking kernel memory each time we
> open/close/delete a file with a different name! I have not figured out
> how to fix the leak in JFFS2 yet. I was wondering whether this
> workaround is safe: Change our SQLite code to always use a fixed
> filename (like mine.db-mjMASTER).

The problem is that if a crash occurs during a multi-file commit,
the master journal cannot be removed from the file-system until
the transactions have been rolled back for all database files.
And this doesn't happen until the first time each of them is
read.

For example, say you have two databases in a transaction - mine.db
and yours.db. A crash happens while committing the transaction
and the file mine.db-mjMASTER is left in the file-system.

Following recovery, if a process tries to read mine.db, the
transaction on mine.db will be rolled back. But the master
journal file cannot be deleted yet (since the interrupted
transaction on yours.db has not yet been reverted).

If the process then attaches "ours.db" and then tries to
write a multi-file transaction that involves mine.db and
ours.db it has a problem - it wants to create and populate
mine.db-mjMASTER but it cannot, since that file is still
in use.

We use the random names to get around this problem.
You could probably get away with using "-mjMASTER1",
"-mjMASTER2" etc. if you wanted to. See the loop around
line 1729 of vdbeaux.c.

Dan.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Reason for random names for the master journal?

[Johns Daniel]

What is the reason was for having random filenames for the SQLite
master journal file (like mine.db-mj501CA440, mine.db-mj1C17,
mine.db-mj66677495, etc)?

Here is the reason for this strange question. We have discovered that
the JFFS2 filesystem in Linux is leaking kernel memory each time we
open/close/delete a file with a different name! I have not figured out
how to fix the leak in JFFS2 yet. I was wondering whether this
workaround is safe: Change our SQLite code to always use a fixed
filename (like mine.db-mjMASTER).

Please advise!

-- Johns
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Hugues Geymond/BR/PRS/BTMEU is out of the office this afternoon.

[hugues . geymond]

I will be out of the office starting  02/24/2011 and will not return until
02/28/2011.

I will respond to your message when I return.
If necessary please contact  M. Fahloul


*
The information contained in this electronic mail message, and any and all 
accompanying documents, constitutes confidential information.  If you are not 
the intended recipient of this information, any disclosure, copying, 
distribution, or the taking of any action in reliance on it is strictly 
prohibited.  If you received this information in error, please notify the 
sender immediately and destroy this communication. Messages sent via this 
medium may be subject to delays and/or unauthorized alteration. Neither The 
Bank of Tokyo-Mitsubishi UFJ, Ltd. nor any of its affiliates shall be held 
liable for the contents of this message.
*
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Parallel execution of queries in threads

[Maddy]

I had tried on sqlite version 3.7.4.
Let me check it on sqlite version 3.7.5.

Thanks,
Madhav

On Thu, Feb 24, 2011 at 9:19 PM, Richard Hipp  wrote:

>
>
> On Thu, Feb 24, 2011 at 4:52 AM, Maddy  wrote:
>
>> Hi,
>> I have 4 "SELECT" queries which are accessing same table.
>> When I executed these queries concurrently using pthreads in Linux, it
>> took
>> approximate 10 Seconds.
>> But same 4 queries executed sequentially it only took 2 seconds.
>> Total Rows in table are 10.
>> Sample query is "SELECT column1, sum(column2) from TABLE_NAME;"
>>
>> What can be the reason behind this?
>>
>
>
> Have you tried this using SQLite version 3.7.5 or are you using a prior
> version of SQLite?
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] memory used by sqlite library

[Michele Pradella]

thank you for the advice, I found even this:
http://www.sqlite.org/malloc.html#memstatus
that describe the possibility to set the memory usage limit

Il 25/02/2011 14.24, Marco Bambini ha scritto:
> Michele take a look at the sqlite3_status function:
> http://www.sqlite.org/c3ref/status.html
> and
> http://www.sqlite.org/c3ref/c_status_malloc_count.html
>
> --
> Marco Bambini
> http://www.sqlabs.com
>
>
>
>
>
>
> On Feb 25, 2011, at 2:17 PM, Michele Pradella wrote:
>
>> Do you know if is there a way to ask to the sqlite library the amount of
>> memory that is using?
>> It could be useful when I have to take a look to the memory used in my
>> application. So I can distinguish between memory allocated by my
>> application itself and allocated by sqlite library.
>> It's possible to set up a maximum amount of memory that the library can use?
>>
>> -- 
>> Selea s.r.l.
>>
>>
>> Michele Pradella R
>>
>>
>> SELEA s.r.l.
>>
>> Via Aldo Moro 69
>> Italy - 46019 Cicognara (MN)
>> Tel +39 0375 889091
>> Fax +39 0375 889080
>> *michele.prade...@selea.com*
>> *http://www.selea.com*
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>


-- 
Selea s.r.l.


Michele Pradella R


SELEA s.r.l.

Via Aldo Moro 69
Italy - 46019 Cicognara (MN)
Tel +39 0375 889091
Fax +39 0375 889080
*michele.prade...@selea.com* 
*http://www.selea.com*
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] memory used by sqlite library

[Marco Bambini]

Michele take a look at the sqlite3_status function:
http://www.sqlite.org/c3ref/status.html
and
http://www.sqlite.org/c3ref/c_status_malloc_count.html

--
Marco Bambini
http://www.sqlabs.com






On Feb 25, 2011, at 2:17 PM, Michele Pradella wrote:

> Do you know if is there a way to ask to the sqlite library the amount of 
> memory that is using?
> It could be useful when I have to take a look to the memory used in my 
> application. So I can distinguish between memory allocated by my 
> application itself and allocated by sqlite library.
> It's possible to set up a maximum amount of memory that the library can use?
> 
> -- 
> Selea s.r.l.
> 
> 
>Michele Pradella R
> 
> 
>SELEA s.r.l.
> 
> Via Aldo Moro 69
> Italy - 46019 Cicognara (MN)
> Tel +39 0375 889091
> Fax +39 0375 889080
> *michele.prade...@selea.com* 
> *http://www.selea.com*
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] memory used by sqlite library

[Michele Pradella]

Do you know if is there a way to ask to the sqlite library the amount of 
memory that is using?
It could be useful when I have to take a look to the memory used in my 
application. So I can distinguish between memory allocated by my 
application itself and allocated by sqlite library.
It's possible to set up a maximum amount of memory that the library can use?

-- 
Selea s.r.l.


Michele Pradella R


SELEA s.r.l.

Via Aldo Moro 69
Italy - 46019 Cicognara (MN)
Tel +39 0375 889091
Fax +39 0375 889080
*michele.prade...@selea.com* 
*http://www.selea.com*
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] COUNT() extremely slow first time!

[Max Vlasov]

On Fri, Feb 25, 2011 at 1:51 AM, Greg Barker  wrote:

> I ran my tests again, this time setting the cache_size based on the
> page_size. For some reason I wasn't able to replicate the timing I got
> before for the 1024 page size (40.2 seconds) which is really confusing me,
> since I was careful to make sure nothing was running in the background
> while
> I was testing.
>
> page_size/cache_size: SELECT COUNT time
> 1024/2000: 20.83s
> 4096/500: 14.4s
> 8192/250: 8.8s
> 16384/125: 5.0s
> 32768/62: 3.6s
>
> I'm assuming reducing the cache size like that will definitely have an
> impact on the performance of an actual application? Optimizing performance
> for an application where both the queries and data can take many different
> shapes and sizes is beginning to seem like quite a daunting task. What do
> you do if there could be anywhere between 30-150 columns?
>
>
Greg, first, I suggest to forget about sqlite cache for scanning operations.
This is because the os cache is also used and it's a known fact that they
sometimes store the same data twice, so disabling or decreasing one still
leaves another in effect.

I saw that the db you have is about 400 MB in size. Giving this, if the
fastest is 3.6 seconds, you have a very fast harddrive. Can you confirm
this? The scanning of such big base with at least 5-years old hd definitely
should be 10 seconds or even slower. Did you reboot your comp this time? By
the way, a faster way to clear the system cache for a particular file is to
"touch" the file with CreateFile(...FILE_FLAG_NO_BUFFERING).

I tried to emulate your base with a table
CREATE TABLE [TestTable] ([Id] Integer Primary key autoincrement, [a] Text,
[b] Text, [c] Text, [d] Text);
and filling it with 1,000,000 records having a, b,c,d about 100 bytes each.
I saw no big difference between 1024 and 8192 page sizes. When copy the db
to Nul took about 20 seconds, 1024-select count took 25 seconds and 8192 -
20 seconds.

Anyway, select count usually is a very slow operation regardless of the
tweaks we can use, almost in every scenario it's equivalent to reading all
the data of the table. I suppose the only exception is if your records is
very big to take advantage of bypassing overflow data. So, probably in a
table with 100 records each containing a 1MB text, 'select count' will be
very fast

Max Vlasov
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] COUNT() extremely slow first time!

[Simon Slavin]

On 24 Feb 2011, at 10:51pm, Greg Barker wrote:

> What do
> you do if there could be anywhere between 30-150 columns?

I would never have any table with 150 columns.  It should be possible to keep 
the schema for your table in your head.

> Optimizing performance
> for an application where both the queries and data can take many different
> shapes and sizes is beginning to seem like quite a daunting task.

For 'daunting' read 'impossible', since the optimal setup will vary over the 
life of the system you're writing, as the tables get bigger, the operating 
system gets slower and the hardware gets faster.  If there was a good general 
solution it would be built into SQLite as the default setting.

There's a big difference between 'fast enough to do what's wanted' and 'as fast 
as possible without heroic measures'.  The first is vital to the success of the 
project.  The second is just bragging rights.  I almost never make performance 
tweaks because although they might save me 600 milliseconds on the sort of 
lookup my users actually do, my users don't notice a difference of 2/3rds of a 
second.

My employer pays about 240 dollars a day for my time.  So for 480 dollars I 
could spend two days optimizing one of my schema or it could buy a faster 
computer (hard disk ?) and speed up not only database access but also 
everything else done with that computer.  Since I have too much to do as it is, 
I'm unlikely to spend the extra two days and emerge with a program which does 
weird things in a weird way just to save a second or two.  I'm curious what my 
customers would have chosen back when I was contracting and being paid a great 
deal more than 240 dollars a day for my time.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] COUNT() extremely slow first time!

[Greg Barker]

I ran my tests again, this time setting the cache_size based on the
page_size. For some reason I wasn't able to replicate the timing I got
before for the 1024 page size (40.2 seconds) which is really confusing me,
since I was careful to make sure nothing was running in the background while
I was testing.

page_size/cache_size: SELECT COUNT time
1024/2000: 20.83s
4096/500: 14.4s
8192/250: 8.8s
16384/125: 5.0s
32768/62: 3.6s

I'm assuming reducing the cache size like that will definitely have an
impact on the performance of an actual application? Optimizing performance
for an application where both the queries and data can take many different
shapes and sizes is beginning to seem like quite a daunting task. What do
you do if there could be anywhere between 30-150 columns?

I'll post the times I got before, when using the default cache_size of 2000:
1024: 40.2s
4096: 15.5s
8192: 8.5s
16384: 5.3s
32768: 3.8s

On Thu, Feb 24, 2011 at 11:19 AM, Greg Barker  wrote:

> Average payload per entry for my test table was 409.00. Sounds about right
> since the db has 4 columns and each is filled with a random string of length
> 100.
>
> I've uploaded the full output from the sqlite3_analyzer for a few different
> page sizes:
>
> http://fletchowns.net/files/1024-analyzer.txt
> http://fletchowns.net/files/4096-analyzer.txt
> http://fletchowns.net/files/8192-analyzer.txt
>
> I'm not quite sure how to interpret everything in there. What stands out to
> you guys? What is Average Fanout?
>
> Greg
>
>
> On Thu, Feb 24, 2011 at 4:28 AM, Max Vlasov  wrote:
>
>> Yes, Greg, please post this value for this table you use in count query
>>
>> Max
>>
>>
>> On Wed, Feb 23, 2011 at 9:58 PM, Greg Barker 
>> wrote:
>>
>> > Is the record size you refer to here the same as the "Average payload
>> per
>> > entry" that sqlite3_analyzer determines for me?
>> >
>> > On Wed, Feb 23, 2011 at 5:09 AM, Max Vlasov 
>> wrote:
>> >
>> > > Greg, you should also take the record size into account. My hypothesis
>> is
>> > > that if your record is comparatively small (several fits into 1024)
>> the
>> > > speed of select count will be the same for any page size (my quick
>> tests
>> > > confirm this). It's interesting to know what is an average size of
>> your
>> > > record to understand why the numbers are so different.
>> > >
>> > > Max
>> >
>> >
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] COUNT() extremely slow first time!

[Greg Barker]

Average payload per entry for my test table was 409.00. Sounds about right
since the db has 4 columns and each is filled with a random string of length
100.

I've uploaded the full output from the sqlite3_analyzer for a few different
page sizes:

http://fletchowns.net/files/1024-analyzer.txt
http://fletchowns.net/files/4096-analyzer.txt
http://fletchowns.net/files/8192-analyzer.txt

I'm not quite sure how to interpret everything in there. What stands out to
you guys? What is Average Fanout?

Greg

On Thu, Feb 24, 2011 at 4:28 AM, Max Vlasov  wrote:

> Yes, Greg, please post this value for this table you use in count query
>
> Max
>
>
> On Wed, Feb 23, 2011 at 9:58 PM, Greg Barker 
> wrote:
>
> > Is the record size you refer to here the same as the "Average payload per
> > entry" that sqlite3_analyzer determines for me?
> >
> > On Wed, Feb 23, 2011 at 5:09 AM, Max Vlasov 
> wrote:
> >
> > > Greg, you should also take the record size into account. My hypothesis
> is
> > > that if your record is comparatively small (several fits into 1024) the
> > > speed of select count will be the same for any page size (my quick
> tests
> > > confirm this). It's interesting to know what is an average size of your
> > > record to understand why the numbers are so different.
> > >
> > > Max
> >
> >
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users