At 23:25 30/05/2007, you wrote:
>--- [EMAIL PROTECTED] wrote:
>> - Original Message
>> > MemPage bitfield patch below.
>> >
>> > sizeof(MemPage) on Linux:
>> >
>> > original: 84
>> > patched: 76
>> > ...
>> > Break-even for memory is 904/8 = 113 MemPage structs allocated.
>>
>>
Here's a naive solution, which requires some programming language
around the SQL:
BEGIN TRANSACTION
n = (SELECT count(*) from table)
i = RandBetween(0, n)
row = (SELECT * from table LIMIT 1 OFFSET i)
END TRANSACTION
I'm posting this because I suspect that this naive solution isn't
correct, but
On Wed, 30 May 2007 15:18:18 -0400, John Elrick wrote
> After running a simple test, I confirmed a suspicion. VACUUM
> doesn't reorder the ROWIDs, so you still have breaks.
My tests show otherwise:
[alex]# cat 01_vacuum_table_test.sql
CREATE TABLE foo (
string varchar(1) not null
);
INSERT
> > If the MemPage are malloced individually (instead of being put in arrays),
> > then they are 16
> byte
> > aligned on most platforms, making the allocated block effectively the same
> > size (well, that
> > depends on how many bytes are used by malloc before the user block in
> > memory).
>
Joe Wilson wrote:
Generally structs are aligned on 8-byte boundaries, so making isInited
a bitfield wouldn't save any additional space in this particular case.
You can combine the other bitfields with isInited at the beginning of
the structure and save a byte later in the structure.
Is there a way I can modify my query to attain a much more equal
distribution? It doesn't have to be perfect, but right now it is too
noticiably weighted.
What about this:
SELECT * FROM Table LIMIT 1 OFFSET round((CAST(random(*) as
float)/(9223372036854775807)+1)/2*(SELECT COUNT(*) FROM
--- Dennis Cote <[EMAIL PROTECTED]> wrote:
> Joe Wilson wrote:
> >
> > If an external interface changed, sure. But these internal structs
> > change constantly from (minor) release to release.
> >
> > The struct in question is used solely by btree.c, so the ordering
> > and layout for bit fields
- Original Message
> From: Dennis Cote <[EMAIL PROTECTED]>
> To: sqlite-users@sqlite.org
> Sent: Wednesday, May 30, 2007 12:09:25 PM
> Subject: Re: [sqlite] sqlite internal structs don't make use of C bitfields?
> You may want to look at how the isInited field is used. You may be able
>
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
> SQLite's typelessness is an asset if you work only with SQLite
> but in any application that uses multiple database engines of
> which SQLite is only one supported engine, the non-standard
> typelessness is something that has to be worked
Alex Teslik wrote:
Hello,
I'm working on a project that requires random images to be chosen from a
live database for a dynamic homepage. I found this link from Dr. Hipp that
details a very fast approach to selecting random rows:
Joe Wilson wrote:
If an external interface changed, sure. But these internal structs
change constantly from (minor) release to release.
The struct in question is used solely by btree.c, so the ordering
and layout for bit fields on different compilers or different platforms
do not matter.
Hello,
I'm working on a project that requires random images to be chosen from a
live database for a dynamic homepage. I found this link from Dr. Hipp that
details a very fast approach to selecting random rows:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg14652.html
- Original Message
> MemPage bitfield patch below.
>
> sizeof(MemPage) on Linux:
>
> original: 84
> patched: 76
> ...
> Break-even for memory is 904/8 = 113 MemPage structs allocated.
I didn't look at the code, so mind me :)
If the MemPage are malloced individually (instead of
--- Dennis Cote <[EMAIL PROTECTED]> wrote:
> There are also some issues with regard to the ordering and layout
> of bitifleds in cross platform applications. I suspect that is the
> reason they aren't used.
If an external interface changed, sure. But these internal structs
change constantly
MemPage bitfield patch below.
sizeof(MemPage) on Linux:
original: 84
patched: 76
Patched "make test" runs without regressions on Linux and Windows.
Timings for "make test" (elapsed):
original: 1:20.74
patched: 1:20.22
Size of sqlite3.o when compiled from almalogmation with all
I have. I placed software hooks into the SQLite memory heap manager and
determined that SQLite allocates memory for most operations and does not give
the memory back until it closes. I didn't look any further as we are out of
time.
Ray
Kalyani Tummala <[EMAIL PROTECTED]> wrote:
> Hi Joe,
afaik strict affininity mode hasn't been implemented.
>From
http://www.sqlite.org/cvstrac/wiki?p=SqliteWikiFaq
"
Q) How can the strict affinity mode be used which is claimed to exist on
http://www.sqlite.org/datatype3.html
A) This has not been implemented as of version 3.3.13.
"
Sam
> I for one would be in favor of an option to enforce strict
> typing (compile time option).
"SQLite version 3 will feature two other affinity modes, as follows:
Strict affinity mode. In this mode if a conversion between storage classes is
ever required, the database engine returns an error and
Joe Wilson wrote:
You could save a few bytes in some sqlite internal structs if you'd
use C bitfields for boolean flags:
For example:
struct MemPage {
u8 isInit; /* True if previously initialized. MUST BE FIRST! */
u8 idxShift; /* True if Cell indices have changed */
u8
struct MemPage2 {
u8 nOverflow;/* Number of overflow cell bodies in aCell[] */
u8 childPtrSize; /* 0 if leaf==1. 4 if leaf==0 */
u8 hdrOffset;/* 100 for page 1. 0 otherwise */
u8 isInit:1; /* True if previously initialized. MUST BE FIRST! */
Okay, maybe not
You could save a few bytes in some sqlite internal structs if you'd
use C bitfields for boolean flags:
For example:
struct MemPage {
u8 isInit; /* True if previously initialized. MUST BE FIRST! */
u8 idxShift; /* True if Cell indices have changed */
u8 nOverflow;
It may not be possible to get peak heap usage down to 30K, but here's
some random ideas:
I imagine you've already tried defining SQLITE_OMIT_* for the features
that you don't need.
Verify that your embedded OS has a space-efficient malloc implementation.
Try to find a realtime graphical heap
Samuel R. Neff schrieb:
SQLite's typelessness is an asset if you work only with SQLite but in any
application that uses multiple database engines of which SQLite is only one
supported engine, the non-standard typelessness is something that has to be
worked around. I for one would be in favor of
SQLite's typelessness is an asset if you work only with SQLite but in any
application that uses multiple database engines of which SQLite is only one
supported engine, the non-standard typelessness is something that has to be
worked around. I for one would be in favor of an option to enforce
Hi Joe,
Yes, SDRAM is normal volatile RAM. Instead of BEGIN ... COMMIT, I have
opened database before insert statement and closed db after that, with
2500 records already stored in the database, temp_store set to 0(file
always), sqlite is taking 48K heap to open the database, 55K for first 5
Hi John,
My main memory is very limited but I have large disk to keep the
database. I need to serialize the data when the device is in switch off
mode or in a different application mode where database is not required.
I need to take care of power failure, data corruption etc.,
I consider your
26 matches
Mail list logo
