Re: [sqlite] What's best table schema?

[Igor Korot]

Moreover, I can't use rowid to communicate between playersinleague and
playersposition tables

Thank you.

On Thu, Jul 4, 2013 at 7:27 PM, Igor Korot  wrote:

> Hi, Simon,
>
> On Thu, Jul 4, 2013 at 6:50 PM, Simon Slavin  wrote:
>
>>
>> On 5 Jul 2013, at 2:10am, Igor Korot  wrote:
>>
>> > CREATE TABLE players(playerid integer primary key, name char(50), age
>> > integer, value integer, currvalue double...);
>> > CREATE TABLE playersinleague(id integer, playerid integer, value
>> integer,
>> > currvalue double, draft boolean, isnew char(1),...);
>> > CREATE TABLE playerpositioninleague(id integer, playerid integer,
>> > positionid integer);
>> >
>> > The problem comes when I try to add a player to a league and later on
>> > delete the new players in the league.
>> > I also need to keep leagues independent, meaning that new players in one
>> > league will not appear on the new league.
>>
>> You don’t need three tables for this, just one.  Have just the player
>> table, but add two fields to it: league and positioninleague.
>>
>
> Good suggestion, but...
> When the user removes new players, it actually means: "bring the league to
> the original state".
> Which means all values for this particular league should be reset to the
> original.
>
> This is why I wanted to keep 2 tables: to simplify the processing  of
> reset algorithm.
>
> Thank you.
>
>
>> I don’t understand the other fields in your playersinleague table, but
>> I’m guessing they can be added to the player table too.
>>
>> Simon.
>> ___
>> 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] What's best table schema?

[Igor Korot]

Hi, Simon,

On Thu, Jul 4, 2013 at 6:50 PM, Simon Slavin  wrote:

>
> On 5 Jul 2013, at 2:10am, Igor Korot  wrote:
>
> > CREATE TABLE players(playerid integer primary key, name char(50), age
> > integer, value integer, currvalue double...);
> > CREATE TABLE playersinleague(id integer, playerid integer, value integer,
> > currvalue double, draft boolean, isnew char(1),...);
> > CREATE TABLE playerpositioninleague(id integer, playerid integer,
> > positionid integer);
> >
> > The problem comes when I try to add a player to a league and later on
> > delete the new players in the league.
> > I also need to keep leagues independent, meaning that new players in one
> > league will not appear on the new league.
>
> You don’t need three tables for this, just one.  Have just the player
> table, but add two fields to it: league and positioninleague.
>

Good suggestion, but...
When the user removes new players, it actually means: "bring the league to
the original state".
Which means all values for this particular league should be reset to the
original.

This is why I wanted to keep 2 tables: to simplify the processing  of reset
algorithm.

Thank you.


> I don’t understand the other fields in your playersinleague table, but I’m
> guessing they can be added to the player table too.
>
> Simon.
> ___
> 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] What's best table schema?

[Simon Slavin]

On 5 Jul 2013, at 2:10am, Igor Korot  wrote:

> CREATE TABLE players(playerid integer primary key, name char(50), age
> integer, value integer, currvalue double...);
> CREATE TABLE playersinleague(id integer, playerid integer, value integer,
> currvalue double, draft boolean, isnew char(1),...);
> CREATE TABLE playerpositioninleague(id integer, playerid integer,
> positionid integer);
> 
> The problem comes when I try to add a player to a league and later on
> delete the new players in the league.
> I also need to keep leagues independent, meaning that new players in one
> league will not appear on the new league.

You don’t need three tables for this, just one.  Have just the player table, 
but add two fields to it: league and positioninleague.

I don’t understand the other fields in your playersinleague table, but I’m 
guessing they can be added to the player table too.

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

[sqlite] What's best table schema?

[Igor Korot]

Hi, ALL,
Consider following task/schema:

CREATE TABLE leagues(id integer primary key, name char(50),);
CREATE TABLE position(positionid integer foreign key, positionname
char(10));
CREATE TABLE players(playerid integer primary key, name char(50), age
integer, value integer, currvalue double...);
CREATE TABLE playersinleague(id integer, playerid integer, value integer,
currvalue double, draft boolean, isnew char(1),...);
CREATE TABLE playerpositioninleague(id integer, playerid integer,
positionid integer);

The problem comes when I try to add a player to a league and later on
delete the new players in the league.
I also need to keep leagues independent, meaning that new players in one
league will not appear on the new league.

It looks like I will not be able to add new player to both players and
playersinleague tables, because leagues needs to be separated.
But if I add the record to only playersinleague table with the value of
null for playerid, I will not be able to add the records in the
playerpositioninleague table.

Can someone please help?

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

Re: [sqlite] table format for most efficient query

[Igor Tandetnik]

On 7/4/2013 5:29 PM, Paul Sanderson wrote:

select * from master as m, lookup as l where x >= start and and x < end and
m.index = l.index


You might want to look at the RTree module:

http://www.sqlite.org/rtree.html

It's specifically designed to implement such range queries efficiently.
--
Igor Tandetnik

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

Re: [sqlite] table format for most efficient query

[Kees Nuyt]

On Thu, 4 Jul 2013 22:52:26 +0100, Simon Slavin 
wrote:

>
> I assume you missed a comma:
>
> create table lookup (index int, start int, end int)

indeed

> But actually it’s a bad idea to use the words
> 'index' and 'end’ for columns because they're
> used as reserved words in SQL. 

I agree.

> So try something like
> create table lookup (rowindex int, rangestart int, rangeend int)

Even better:

create table lookup (
rowindex INTEGER PRIMARY KEY
,   rangestart int
,   rangeend int
);

This way, rowindex aliases the internal ROWID column, saving an integer
column. Also, JOIN performance on rowindex will be better as it removes
one level of indirection.

-- 
Groet, Cordialement, Pozdrawiam, Regards,

Kees Nuyt

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

Re: [sqlite] table format for most efficient query

[Paul Sanderson]

Thanks Simon - i'll have a play. tomorrow




On 4 July 2013 22:52, Simon Slavin  wrote:

>
> On 4 Jul 2013, at 10:29pm, Paul Sanderson 
> wrote:
>
> > create table lookup (index int, start int end int)
>
> I assume you missed a comma:
>
> create table lookup (index int, start int, end int)
>
> But actually it’s a bad idea to use the words 'index' and 'end’ for
> columns because they're used as reserved words in SQL.  So try something
> like
>
> create table lookup (rowindex int, rangestart int, rangeend int)
>
> > The takle will be joined on a second table via the index column
> >
> > the table is likely to have a few million rows and I will be doing many
> > thousands of lookups consequtively. My current lookups are of the form
> >
> > select * from master as m, lookup as l where x >= start and and x < end
> and
> > m.index = l.index
>
> Presumably
>
> select * from master as m, lookup as l where m.x >= l.rangestart and m.x <
> l.rangeend and m.rowindex = l.rowindex
>
> > i sthere an efficient way of doing this - 30,000 lookups on two table
> seach
> > with about 1 million rows is taking about 30 minutes.
> >
> > Can I structure my lookup table differently?
>
> Don’t do a * unless you actually need * of both tables.  List the columns
> you are actually going to use.
>
> > would indexes help in anyway?
>
> SELECT * FROM master AS l JOIN lookup AS l ON master.rowindex =
> lookup.rowindex WHERE m.x >= l.rangestart AND m.x < l.rangeend
>
> Good indexes for that would be
>
> CREATE INDEX masterRX ON master (rowindex, x)
> CREATE INDEX lookupRR ON lookup (rowindex, rangestart)
>
> You can speed things up even more by doing an ANALYSE once you have data
> in the tables.  This lets SQLite figure out that your lookup table is huge
> and tune its query plans accordingly.
>
> Simon.
> ___
> 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] table format for most efficient query

[Simon Slavin]

On 4 Jul 2013, at 10:29pm, Paul Sanderson  wrote:

> create table lookup (index int, start int end int)

I assume you missed a comma:

create table lookup (index int, start int, end int)

But actually it’s a bad idea to use the words 'index' and 'end’ for columns 
because they're used as reserved words in SQL.  So try something like

create table lookup (rowindex int, rangestart int, rangeend int)

> The takle will be joined on a second table via the index column
> 
> the table is likely to have a few million rows and I will be doing many
> thousands of lookups consequtively. My current lookups are of the form
> 
> select * from master as m, lookup as l where x >= start and and x < end and
> m.index = l.index

Presumably

select * from master as m, lookup as l where m.x >= l.rangestart and m.x < 
l.rangeend and m.rowindex = l.rowindex

> i sthere an efficient way of doing this - 30,000 lookups on two table seach
> with about 1 million rows is taking about 30 minutes.
> 
> Can I structure my lookup table differently?

Don’t do a * unless you actually need * of both tables.  List the columns you 
are actually going to use.

> would indexes help in anyway?

SELECT * FROM master AS l JOIN lookup AS l ON master.rowindex = lookup.rowindex 
WHERE m.x >= l.rangestart AND m.x < l.rangeend

Good indexes for that would be

CREATE INDEX masterRX ON master (rowindex, x)
CREATE INDEX lookupRR ON lookup (rowindex, rangestart)

You can speed things up even more by doing an ANALYSE once you have data in the 
tables.  This lets SQLite figure out that your lookup table is huge and tune 
its query plans accordingly.

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

[sqlite] table format for most efficient query

[Paul Sanderson]

I need to craete a lookup table which has the form

create table lookup (index int, start int end int)

The takle will be joined on a second table via the index column

the table is likely to have a few million rows and I will be doing many
thousands of lookups consequtively. My current lookups are of the form

select * from master as m, lookup as l where x >= start and and x < end and
m.index = l.index

i sthere an efficient way of doing this - 30,000 lookups on two table seach
with about 1 million rows is taking about 30 minutes.

Can I structure my lookup table differently? would indexes help in anyway?

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

Re: [sqlite] Another 2 questions about SQLite

[Kees Nuyt]

On Thu, 4 Jul 2013 15:15:14 -0400, "James K. Lowden"
 wrote:

> This weird case is one of (I would say) misusing the connection.  IMO
> SQLite should return an error if prepare is issued on a connection for
> which a previous prepare was not finalized or reset.  That would
> forestall discussions like, this and prevent confusion and error.  

Not the _prepare() is critical, but the first call of_step() after
_prepare() or _reset().
In fact it is a nice feature to prepare (a whole bunch of) statements in
advance (which runs the optimizer and generates the code for the virtual
machine) and reuse them (with different bindings). 

Every use (AKA statement execution) is: 
loop
_bind()
_step()
... other stuff
endloop
_reset()

At program init: _prepare()
At program exit: _finalize()

Re-prepare() is only necessary when the schema changes, and can be
automatic in some versions of _prepare().
In most applications the schema is quite static.

my EUR 0.02

-- 
Groet, Cordialement, Pozdrawiam, Regards,

Kees Nuyt

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

Re: [sqlite] Another 2 questions about SQLite

[Igor Tandetnik]

On 7/4/2013 3:15 PM, James K. Lowden wrote:

This weird case is one of (I would say) misusing the connection.  IMO
SQLite should return an error if prepare is issued on a connection for
which a previous prepare was not finalized or reset.  That would
forestall discussions like, this and prevent confusion and error.


SQLite worked this way, years ago. At some point, the restriction was 
removed by popular demand. It is hugely convenient to be able to 
manipulate one table as you iterate over another. You do have to be 
careful not to modify the same data you are iterating over, but it's 
still way better than being unable to make any changes at all. We (the 
SQLite users) have seen this movie before, and we didn't like it.

--
Igor Tandetnik

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

Re: [sqlite] Another 2 questions about SQLite

[Igor Tandetnik]

On 7/4/2013 3:15 PM, James K. Lowden wrote:

If two processes sharing a connection...


This is a physical impossibility. There ain't no such thing as two 
processes sharing a connection.

--
Igor Tandetnik

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

Re: [sqlite] Another 2 questions about SQLite

[Simon Slavin]

On 4 Jul 2013, at 8:15pm, James K. Lowden  wrote:

> It doesn't usually matter, right?  The fact that the atomic SELECT is
> spread out across N function calls is irrelevant if they are executed
> in uninterrupted sequence, because other connections are blocked from
> modifying the affected tables until the SELECT is finalized.  

Right.  The supported, cannonical, predictable, deterministic way to use 
_prepare() is to get all the way from _prepare() to _finalize() without doing 
anything but use that statement.  And if you do that it doesn’t matter 
precisely which call does the lock and which one does the unlock.

In real life SQLite allows many other things to happen.  But predicting what 
happens then requires a detailed understanding of SQLite.  Which means you’re 
starting to mess with things that can change with different versions.  Which is 
to be avoided unless it’s really useful to you.

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

Re: [sqlite] DLL Size differences and other info requested

[James K. Lowden]

On Thu, 4 Jul 2013 17:36:37 +0200
Philip Bennefall  wrote:

> Do you have any views on compiling SqLite optimized for speed rather
> than size?

These days, size is speed.  The smaller the code, the better it fits in
cache, the faster it runs.  The days of unrolling loops to avoid
branches in the pipeline are long gone.  

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

Re: [sqlite] Another 2 questions about SQLite

[Stephan Beal]

On Thu, Jul 4, 2013 at 9:15 PM, James K. Lowden wrote:

> On Mon, 01 Jul 2013 23:59:15 -0400
> Igor Tandetnik  wrote:
>
> > > 2.  Trying to re-use a single connection to issue a second query
> > > before finalizing the first one should return an error
> >
> > No it should not, and does not. Try it.
> >
> > > because the library is being improperly used.
> >
> > That may be, but it doesn't result in an error.
>

FWIW, just a bit of trivia: for MySQL you can't do two concurrent selects
on the same connection. Its over-the-wire protocol does not support
traversing two selects at the same time. Wrappers which allow that hide
that by loading/caching all data from the first select in advance.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Another 2 questions about SQLite

[James K. Lowden]

On Tue, 2 Jul 2013 11:57:43 +0100
Simon Slavin  wrote:

> The SELECT statement is fine and consistent.  But the SELECT
> statement is all of _prepare(), _step(), and _finalize().  Igor is
> pointing out that that if you stop before _step() has returned
> SQLITE_DONE then you haven?t /done/ a SELECT statement, you?ve just
> started one and it is still, in his word, "live".

That's very interesting.  I've spent many hours reading the SQLite
documentation, and just reviewed sqlite3_step().  The only hint I find
to that effect is that sqlite3_step "must be called one or more times
to *evaluate* the statement" (my emphasis).  There is no metion of when
locks are established or how atomicity is enforced.  

It doesn't usually matter, right?  The fact that the atomic SELECT is
spread out across N function calls is irrelevant if they are executed
in uninterrupted sequence, because other connections are blocked from
modifying the affected tables until the SELECT is finalized.  

This weird case is one of (I would say) misusing the connection.  IMO
SQLite should return an error if prepare is issued on a connection for
which a previous prepare was not finalized or reset.  That would
forestall discussions like, this and prevent confusion and error.  

> > So I still don't see how the SELECT could be anything
> > undeterministic. 
> 
> It's not predictable in any simple way because its behaviour changes
> depending on lots of things like whether there?s a covering index,
> and what other threads do things with the database and when. So you
> can't write a simple set of rules that it?ll always follow: it does
> different things under different circumstances.

I take that to mean that the information returned is deterministic, but
how it is executed and the order in which the rows are returned
varies.  Acknowledged.  I just think it's a bad idea, under any
circumstances, to allow the number of columns returned by a SELECT
statement to vary during its "evaluation" between steps.  

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

Re: [sqlite] Another 2 questions about SQLite

[James K. Lowden]

On Mon, 01 Jul 2013 23:59:15 -0400
Igor Tandetnik  wrote:

> > 2.  Trying to re-use a single connection to issue a second query
> > before finalizing the first one should return an error
> 
> No it should not, and does not. Try it.
> 
> > because the library is being improperly used.
> 
> That may be, but it doesn't result in an error.

Hmm, is this considered a bug or a feature?  

To me, the SQLite library should enforce deterministic outcomes.  If
two processes sharing a connection can undermine the atomicity of the
exectution of an SQL statement, the library fails that test.  

--jkl

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

Re: [sqlite] Is there a way to return the row number? (NOTthe rowid)

[James K. Lowden]

On Wed, 3 Jul 2013 22:49:51 -0500
"Jay A. Kreibich"  wrote:

>   So anyways, I don't actually care about the actual number of orders,
>   which is mostly likely what my SQL query returns, I just want the
>   ranking-- who is first, second, and third.  I can get that from an
>   ORDER BY query, but the data that makes up the result set doesn't
>   actually contain the information I want.  The information I want is
>   encoded into the row order of the result set, not the data values of
>   the result.  In other words, the row order is extremely relevant,
> and part of the desired result itself.   That's about as
> non-Relational as you can get.

I enjoyed your post, Jay, and hereby place my  bet that it wins HAVING
MAX(COUNT(words)) FROM sqlite-users for July.  ;-)  

I beg to differ on this bit of your analysis, though.  To say the
rank information you want is "encoded in the order" is like saying the
count information is encoded in the number of rows produced.  What you
really mean is that one is derived from the other.  True, you can infer
what you want to know from what you see, but you can also compute it
(by counting, or by counting the lessers).  Nothing non-relational
about it.  

> "Give me a list of the top 10 sales regions for
>   last quarter, ranked by total number of orders."
...
>   Of course the result is very non-Relational, since the inherent
>   information I asked for is dependent on row order

No row order is implied.  Rank depends not on *row* order, but on total
number of orders.  There is no reason the rows couldn't be displayed in
another order (say, by region name) causing their ranks to appear in
4,3,6,8,9,2... order.  The fact that the query can be expressed in SQL
without reference to a row number confirms the point.  

That's good news: the relational heart of SQL, however trampled and
starved, still beats on.  

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

Re: [sqlite] Is there a way to return the row number? (NOT the rowid)

[James K. Lowden]

On Wed, 03 Jul 2013 11:11:29 +0200
Gabriel Corneanu  wrote:

> I reply from the web and I can't easily quote.

Acknowledged, but it does make the thread more difficult to read.  :-/  

> I don't really want to argue whether it's a workaround or not. I 
> understand perfectly that's valid standard sql.
> However please accept that the given sql is quite complex; you have
> to duplicate in the join clause the ordering...

SQL never won any prizes for elegance of expression.  It's verbose and
redundant.  Yet it still manages to accomplish more with less than any
"modern" programming language you care to name.  

> explain query plan
> select count(lesser.rowid) as RANK, S.rowid, S.chan
> from params as S
> left outer join params as lesser
> on   S.chan >= lesser.chan
> group by S.rowid
> order by S.chan
> 
> This gives:
> SCAN TABLE params AS S USING INTEGER PRIMARY KEY
> SEARCH TABLE params AS lesser USING COVERING INDEX 
> sqlite_autoindex_params_1 (Chan USE TEMP B-TREE FOR ORDER BY

Yes, and there's your O(N log N): N for the SCAN and log(N) for the
SEARCH. To process 1,000,000 rows takes 1,000,000 accesses.  To produce
the rank requires roughly 20 searches per row (given an appropriate
index), or 20,000,000 total accesses. Plus some work, depending on
memoization, to count the nodes beneath the found one.  

Inefficient? It's the theoretical *minimum* for the general case.  

In the particular case, the system has an (unexploited) opportunity to
reduce the complexity to O(N): If it "notices" that row N depends on
N-1, it can simply bump the counter.  

A system-provided RANK() function could do no better.  It might be
easier for the parser to recognize the optimization opportunity, and it
might be easier to type.  But changing the syntax doesn't affect the
semantics, and semantics drive the algorithm.  

Your original question wasn't about ranking, but simply counting the
rows "in order", which presumably wouldn't require comparing the table
to itself.  But I very much doubt that order doesn't matter  I suspect
that whenever "row number" matters, the rows are ordered by *something*
(age, date, size, quantity, name, etc.).  For them to be ordered, they
had to be sorted, and there we are again back at O(N log N).  

Did I miss something, or have I answered your efficiency concerns?  

AIUI your other concern is about ease of use, that it's easier to type
RANK(a,b,c) than to write a self-join.  You may be right; ISTR using
just such a function on other systems myself.  I would nevertheless
argue against adding one to SQLite.  SQL it redundant enough as it is.
I don't know what my policy would be for nominating a new function, but
I'm sure that "eliminates one join" sets the bar too low.   

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

Re: [sqlite] DLL Size differences and other info requested

[Simon Slavin]

On 4 Jul 2013, at 4:36pm, Philip Bennefall  wrote:

> Thanks for that info. Do you have any views on compiling SqLite optimized for 
> speed rather than size? Is the difference in performance generally small 
> enough to be ignored? I am using Vc++ 2010 express and have been optimizing 
> for speed up until now.

Optimizing for anything only matters when that thing matters.  In these days of 
fast computers and cheap memory computers spend most of their time waiting for 
you to type something and every memory device has a gigabyte or two free.

Ignore optimization, or just go with whatever the defaults are, until you get 
dissatisfied with that thing.  Spend more time on making your application more 
fun to use.

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

Re: [sqlite] DLL Size differences and other info requested

[Philip Bennefall]

Hi Dan,

Thanks for that info. Do you have any views on compiling SqLite optimized 
for speed rather than size? Is the difference in performance generally small 
enough to be ignored? I am using Vc++ 2010 express and have been optimizing 
for speed up until now.


Kind regards,

Philip Bennefall
- Original Message - 
From: "Dan Kennedy" 

To: 
Sent: Thursday, July 04, 2013 5:12 PM
Subject: Re: [sqlite] DLL Size differences and other info requested


On 07/04/2013 05:49 AM, Philip Bennefall wrote:

Hi Stephen,

I don't know what compiler is used to build the official SqLite dll,
but provided it is some version of Vc++ my experience is that MinGw
often produces larger and sometimes significantly slower binaries on
Windows than VC++ does. In an unrelated project of mine, the binary
size dropped by about 500 KB when I switched from Dev-C++/MinGw to
Code::Blocks/MSVC++. This is mere speculation on my part in this case,
however, as I don't actually know what compiler that is being used to
build the official dll.


Those on the website are built with mingw 4.5.2 using:

  -Os
  -DSQLITE_ENABLE_FTS3
  -DSQLITE_ENABLE_RTREE
  -DSQLITE_ENABLE_COLUMN_METADATA

In case anyone was wondering.


___
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] DLL Size differences and other info requested

[Dan Kennedy]

On 07/04/2013 05:49 AM, Philip Bennefall wrote:

Hi Stephen,

I don't know what compiler is used to build the official SqLite dll, 
but provided it is some version of Vc++ my experience is that MinGw 
often produces larger and sometimes significantly slower binaries on 
Windows than VC++ does. In an unrelated project of mine, the binary 
size dropped by about 500 KB when I switched from Dev-C++/MinGw to 
Code::Blocks/MSVC++. This is mere speculation on my part in this case, 
however, as I don't actually know what compiler that is being used to 
build the official dll.


Those on the website are built with mingw 4.5.2 using:

  -Os
  -DSQLITE_ENABLE_FTS3
  -DSQLITE_ENABLE_RTREE
  -DSQLITE_ENABLE_COLUMN_METADATA

In case anyone was wondering.


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