Re: [sqlite] sqlite versus MySQL automatic defragmentation on SSDs?

[David Barrett]

Ah, to clarify, there is only one "master" at any point in time.  So this
isn't a "multi-master" scenario where each node keeps committing locally
and then somehow merging the results later.  Rather, each node knows if
it's the master or slave (or a variety of other states).  If it's a master,
it organizes the two-phase distributed commit.  If it's a slave, it
escalates to the master.  And if it's something else, then it just holds on
to the request and waits until it's either a slave or a master.

-david


On Wed, Oct 31, 2012 at 2:09 AM, Chris Peachment  wrote:

> On Wed, 2012-10-31 at 00:49 +0700, David Barrett wrote:
> > Thanks Alek!  Yes, we're definitely planning on it, just trying to
> > find the right time.  We don't want to go through the work to open
> > source it only to be greeted with silence.  Might you be interested in
> > using it in an actual deployed environment, or just studying it?
> >
> >
> Your proposal to open source the replication method used by Expensify
> has me interested. My application of interest is much smaller than
> yours, just a handful of remote clients that risk loss of connectivity
> but wish to continue with database updates during the downtime.
>
> Aside from the details of protocol usage and statement packaging, the
> concern for collisions during merge is a particular issue of interest.
>
> Chris
>
>
> ___
> 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] light weight write barriers

[Nico Williams]

Hmm, so sorry I didn't notice the cc'ing of the linux-kernel list,
resulting in so much additional traffic to sqlite-users, which I'll
drop in my replies to the linux-kernel list.

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

Re: [sqlite] Union all writting on /var/tmp

[Nico Williams]

Also, as far as I'm concerned, if the choice is "more optimizations in
SQLite3" or "more work on SQLite4", then put me down for the latter.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] light weight write barriers

[Howard Chu]

On Thu, Oct 25, 2012, Nico Williams wrote:

Incidentally, here's a single-file, bag of b-trees that uses a COW
format: MDB, which can be found in
git://git.openldap.org/openldap.git, in the mdb.master branch.


Complete docs, design notes, and benchmark results are available here:
  http://highlandsun.com/hyc/mdb/

I already discussed some of this on the sqlite-dev mailing list back in July.
I'll also be giving a talk on the design/internals of MDB in Barcelona at 
LinuxCon Europe on Wednesday November 7. Drop by if you're in the area...


Our work on an sqlite 4 backend built on MDB is progressing as well.
--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Union all writting on /var/tmp

[Nico Williams]

On Mon, Oct 29, 2012 at 8:08 PM, Richard Hipp  wrote:
> The reason for using a temp table for UNION ALL in a subquery is because
> that is the path of least resistance.  [...]

For what it's worth, UNION ALL is generally understood to be a major
optimization over UNION because no temp table should be required to
implement UNION ALL;.  Also, IIUC, INTERSECT and EXCEPT could also be
run without temp tables by converting them to slightly different
queries: SELECT ... FROM source1 ... WHERE EXISTS (SELECT ... FROM
source2 ...).  And UNION ALL queries could be re-written into a UNION
where the second query is an EXCEPT query (all the rows in the second
that are not in the first).  INTERSECT and EXCEPT are not used very
frequently, but UNION ALL is used quite frequently, and probably much
more so than UNION: UNION ALL is the logical operator for building
VIEWs to implement a SQL equivalent of virtual classes, with each
virtual class implemented as the UNION ALL of several queries.  It
would be quite worthwhile to have UNION ALL not use a temp table.

Incidentally, there are a lot of possible optimizations where a query
could be re-written differently where the optimizer could be external
to SQLite, using a parser that objectifies SQL, an analyzer, and a
re-writer that outputs SQL to be parsed by SQLite.  Optimizations like
GCSE, OR -> UNION, INTERSET/EXECPT -> SELECT ... WHERE EXISTS / NOT
EXISTS, and others.  But UNION ALL cannot be so re-written, and that,
I think, is a good argument for having this optimization in SQLite
while not necessarily having the others.  I've been tempted before to
write at least the objectifying parser for this.

> At http://www.sqlite.org/src/info/7af3acbbd4 there is a patch that adds the
> optimization to avoid using a temp table for your UNION ALL queries.  This
> one small patch represents about 12 hours of intense work, so far.  Much
> more work will be required to get the patch performing to our release
> standards.  All of this effort on your behalf you are receiving for free.
> In return, we ask two things:

We all appreciate this very much.  It is a lot of work, I know.

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

[sqlite] MyJSQLView Version 3.40 Released

[danap]

MyJSQLView Version 3.40 Released

The MyJSQLView project is pleased to release v3.40 to the public. The
release marks a major reorganizational effort to the source code and
plugin management. Though the public will notice little with regard
to the source subpackaging the plugin management changes bring the
ability to now load plugins from remote locations. Plugin repositories
can now be created by individuals or organizations that wish to provide
custom plugins on the basis of a realtime network loading capability.
In that regard the MyJSQLView project has added to its own public
repository a free open source plugin that contains a graphical SQL
query builder. MyJSQLView works in conjuction with the Xerial SQLite
JDBC to access a SQlite database file.

Dana M. Proctor
MyJSQLView Project Manager
http://dandymadeproductions.com/projects/MyJSQLView/
http://www.xerial.org

MyJSQLView provides an free open source easy to use Java based user
interface frontend for viewing, adding, editing, or deleting entries
in several mainstream databases. A query frame allows the building
of complex SQL statements and a SQL Query Bucket for saving such. The
application allows easy sorting, searching, and import/export of table
data. A plug-in framework has allowed the inclusion of tools to profile
and plot data for analysis.

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

Re: [sqlite] sqlite versus MySQL automatic defragmentation on SSDs?

[Chris Peachment]

On Wed, 2012-10-31 at 00:49 +0700, David Barrett wrote:
> Thanks Alek!  Yes, we're definitely planning on it, just trying to
> find the right time.  We don't want to go through the work to open
> source it only to be greeted with silence.  Might you be interested in
> using it in an actual deployed environment, or just studying it?
> 
> 
Your proposal to open source the replication method used by Expensify
has me interested. My application of interest is much smaller than
yours, just a handful of remote clients that risk loss of connectivity
but wish to continue with database updates during the downtime.

Aside from the details of protocol usage and statement packaging, the
concern for collisions during merge is a particular issue of interest.

Chris


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

Re: [sqlite] sqlite versus MySQL automatic defragmentation on SSDs?

[Simon Slavin]

On 30 Oct 2012, at 5:15pm, David Barrett  wrote:

> I'm encouraged to hear
> that there aren't any particular size restrictions or concerns.



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

Re: [sqlite] sqlite versus MySQL automatic defragmentation on SSDs?

[David Barrett]

On Tue, Oct 30, 2012 at 1:00 AM, Alek Paunov  wrote:

> On 29.10.2012 11:58, David Barrett wrote:
>
>> Because in practice, as someone actually doing it (as opposed to
>> theorizing
>> about it), it works great.  The MySQL portions of our service are always
>> in
>> a semi-constant state of emergency, while our sqlite portions just hum
>> along   And given that we're switching to SSDs, I expect they will hum
>> even
>> better.  What problems would you expect me to be seeing that I can happily
>> report I'm not, or what problems have I not yet encountered but will -- at
>> 100GB, or 1TB?
>>
>
> In your previous thread (2012-02), you have mentioned that you are about
> to open-source your replication method based on SQL statement distribution.
> Probably your work would be of interest for a huge number of sites managing
> data volumes around or bellow your current level, even if you switch to
> PostgreSQL at this point.
>
> IMHO, there might be a future for your replication model, because I think
> that SQLite, can more easily (relative to other proven DB technologies e.g.
> PostgreSQL) be turned to DB engine for more query languages than SQL
> (thanks to his clever VM design).
>
> Furthermore, AFAIK, PostgreSQL replicates at WAL distribution level, most
> NoSQL databases at keys distribution level, whereas your method seems more
> efficient as bandwidth.
>

Thanks Alek!  Yes, we're definitely planning on it, just trying to find the
right time.  We don't want to go through the work to open source it only to
be greeted with silence.  Might you be interested in using it in an actual
deployed environment, or just studying it?

As for the size this works up to, I should emphasize that Expensify uses
this for our main database -- and we have over a *million* users on it.
 That's not to say a million users is the biggest thing ever, but it's a
lot bigger than most websites (with far more complicated data structures),
and it works great.  Furthermore, we're in the process of upgrading all our
hardware and we feel that alone will get us at *least* an order of
magnitude improvement in capacity -- wiithout any algorithmic changes.  And
we've got plenty of ideas how to improve the basic technology and/or
restructure our database to get even more capacity, should we need it.

The upshot is I don't see a specific reason why it couldn't scale up to a
5M, 10M, or larger service.  And if it starts to break down after that?
 Well that's a problem we should all love to have.

Additionally, I think people get so excited about big data that they
overlook the importance of *available* data.  With this technology,
everything is replicated offsite in realtime, ensuring that service can
continue uninterrupted even when a whole datacenter goes underwater (as is
happening to many datacenters at this very moment in NYC) or falls off the
map (as happens to various AWS zones with surprising regularity).  Our
technology seamlessly fails over when any node (even the master) disappears
(or reappears), without dropping a single transaction -- the web layer
doesn't even know if it's talking to a master or slave, or it was a slave
that became master mid-transaction.

This total confidence in the data layer is what allows us to sleep soundly
even when servers crash: similar to how Google only fixes broken servers
every quarter, any business in this day and age that stresses out when a
server dies is doing it wrong.  Indeed, i'm writing this from a hotel in
Bangkok because every year we take the whole company overseas for a month
to work from the beach -- something that would be inconceivable to an
organization that puts all its eggs in one datacenter.

As for SQL versus binary replication, it has its pros and cons -- it's
generally (though not always) more bandwidth efficient, but at a higher CPU
cost: slaves need to redo all the work as the master.  But it's
fantastically simple, and I feel a simple design brings the most important
efficiency of all: easy to understand, easy to debug, easy to verify.

As for Postgre, MySQL, or any other database back end -- yes, it'd designed
to be a layer above the database.  We're in the midst of making it
optionally backed by a MySQL store, but yes, it should be easy to put
anything behind it.

Finally, that's interesting about using this to replicate non-SQL languages
-- yes, it's definitely language agnostic.  Anything that has the notion of
an atomic transaction with ROLLBACK and COMMIT should work fine with it.

Thanks for the interest!

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

Re: [sqlite] sqlite versus MySQL automatic defragmentation on SSDs?

[David Barrett]

On Mon, Oct 29, 2012 at 8:28 PM, Richard Hipp  wrote:

> On Mon, Oct 29, 2012 at 5:58 AM, David Barrett  >wrote:
> > So what specifically do you feel is the problem with sqlite at scale?
> >
> > And to be clear, I'd like to pre-empt "well it doesn't do X, which you'll
> > probably also want to do" -- all those X's are already covered and
> working
> > great.


Generally the argument in favor of client/server databases versus SQLite
> comes down to (1) Concurrency, (2) Replication, and (3) Network access.
> The size of the database file shouldn't really be a factor.


Yes, thank you, I'm sorry I didn't make it clear -- concurrency,
replication, and network access are *not* problems for me.  Specifically:

1) Our server is single-threaded (all writes are serialized), so there are
no concurrency issues.
2) We have our own replication layer (which is better than MySQL and
Postgres replication)
3) We provide our own network access (on top of the replication layer)
4) The backup API works fine
5) Everything is on the local disk

So I agree entirely -- if you need something sqlite doesn't provide, then
sqlite isn't the right choice.  I'm just saying sqlite provides everything
I need, and does it incredibly well.  Similarly, I'm encouraged to hear
that there aren't any particular size restrictions or concerns.  We're
currently at 40GB and it's working great.

But back to the original question -- can anybody point me in a direction to
learn more about MySQL's handling of fragmentation and how it differs from
sqlite?  This isn't an obsession, it doesn't even really affect us in light
of our moving to SSDs.  It's just a gap in my knowledge I'm looking to
fill.  Thanks!

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

Re: [sqlite] Union all patch, preliminary tests

[Richard Hipp]

Thanks for running these tests.  Clearly I should have made this change a
long time ago

On Tue, Oct 30, 2012 at 9:31 AM, Eleytherios Stamatogiannakis <
est...@gmail.com> wrote:

> In my preliminary tests, the patch has worked wonderfully. In these first
> tests i have only tested plain SQLite functionality (without virtual table
> or additional functions) on a 1.5GB DB. Some remarks:
>
> - It is lightning fast. For queries that fit to the free space (some of
> them could not finish before due to space constraints) and previously took
> minutes to finish, with the patch they are instantaneous and they do not
> touch the drive. The results are the same.
>
> - I was expecting that only simple scans over unioned queries would be
> affected by the patch. When i tried to do a filter on a unioned table
> composition, and the query was again instantaneous, i was flabbergasted.
> The patch really pushes index accesses downwards into the unioned tables. I
> didn't expect the patch to go that far. I'm amazed,
>
> - Group by on unioned all tables was also instantaneous without filling
> the hard disk.
>
> - Oddly, order by works the same both with the patch and without the patch
> (SQLite 3.7.14.1). I assume that order by had a similar optimization in
> previous versions of SQLite too?
>
> - On all of the above tests, the free space on the hard disk wasn't
> affected by the running query.
>
> More tests will be done in the context of madIS, but they will take more
> time. I want to test plain SQLite first, because this is what most people
> will use in practise.
>
> Best regards,
>
> lefteris.
>
>
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>



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

[sqlite] Union all patch, preliminary tests

[Eleytherios Stamatogiannakis]

In my preliminary tests, the patch has worked wonderfully. In these 
first tests i have only tested plain SQLite functionality (without 
virtual table or additional functions) on a 1.5GB DB. Some remarks:


- It is lightning fast. For queries that fit to the free space (some of 
them could not finish before due to space constraints) and previously 
took minutes to finish, with the patch they are instantaneous and they 
do not touch the drive. The results are the same.


- I was expecting that only simple scans over unioned queries would be 
affected by the patch. When i tried to do a filter on a unioned table 
composition, and the query was again instantaneous, i was flabbergasted. 
The patch really pushes index accesses downwards into the unioned 
tables. I didn't expect the patch to go that far. I'm amazed,


- Group by on unioned all tables was also instantaneous without filling 
the hard disk.


- Oddly, order by works the same both with the patch and without the 
patch (SQLite 3.7.14.1). I assume that order by had a similar 
optimization in previous versions of SQLite too?


- On all of the above tests, the free space on the hard disk wasn't 
affected by the running query.


More tests will be done in the context of madIS, but they will take more 
time. I want to test plain SQLite first, because this is what most 
people will use in practise.


Best regards,

lefteris.


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

Re: [sqlite] sqlite eclipse

[Black, Michael (IS)]

Sounds ilke you're using a 64-bit JDK.
Use the 32-bit JDK.
That's what the error is telling you64-bit can't load 32-bit DLL.
As long as all your code is 32-bit it will run on 32-bit.

Michael D. Black
Senior Scientist
Advanced Analytics Directorate
Advanced GEOINT Solutions Operating Unit
Northrop Grumman Information Systems


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of Kemayou Nyamen, Carine, WO [carine.kemayounya...@de.bertrandt.com]
Sent: Tuesday, October 30, 2012 7:45 AM
To: sqlite-users@sqlite.org
Subject: EXT :[sqlite] sqlite  eclipse

Hello,

I want to connect to my database sqlite via eclipse. I write a java programm, 
but It is not possible,  I read the  Instruction on this site Connecting to 
SQLite - Eclipsepedia  , but when 
I make test connection, the error is ping failed. By run the java program 
java.lang.UnsatisfiedLinkError: 
C:\Users\kemayouc\AppData\Local\Temp\sqlitejdbc.dll: Can't load IA 32-bit .dll 
on a AMD 64-bit platform .   I have Window 7 and 64 Bit Operating System.  
Thanks in advance for your Help.



Mit freundlichen Grüßen

i. A. Carine Kemayou Nyamen

Elektronik / Software



Bertrandt Ingenieurbüro GmbH

Krümke 1

D-38479 Tappenbeck



Telefon:+49 5366 9611-1845

Telefax: +49 5366 9611-1100

Internet:http://www.bertrandt.com 

E-Mail:  mailto:carine.kemayounya...@de.bertrandt.com



Geschäftsführer: Ulrich Subklew

Sitz der Gesellschaft: Tappenbeck, Amtsgericht: Braunschweig, HRB 100280



The contents of this e-mail are confidential. If you are not the named 
addressee or if this transmission has been addressed to you in error, please 
notify the sender immediately and then delete this e-mail. Any unauthorized 
copying and transmission is forbidden.
E-mail transmission cannot be guaranteed to be secure. If verification is 
required, please request a hard copy version. Please note, that incoming e-mail 
is not checked regularly. This may result in a failure to comply with legal or 
contractual terms. Therefore it is not sufficient, to send any legal or 
contractual declarations by e-mail. In no event will Bertrandt be liable to you 
or any third party for any direct, indirect, consequential, special or 
exemplary damages or lost profit resulting from this failure.





___
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] sqlite eclipse

[Kemayou Nyamen, Carine, WO]

Hello,

I want to connect to my database sqlite via eclipse. I write a java programm, 
but It is not possible,  I read the  Instruction on this site Connecting to 
SQLite - Eclipsepedia  , but when 
I make test connection, the error is ping failed. By run the java program 
java.lang.UnsatisfiedLinkError: 
C:\Users\kemayouc\AppData\Local\Temp\sqlitejdbc.dll: Can't load IA 32-bit .dll 
on a AMD 64-bit platform .   I have Window 7 and 64 Bit Operating System.  
Thanks in advance for your Help.

 

Mit freundlichen Grüßen

i. A. Carine Kemayou Nyamen

Elektronik / Software

 

Bertrandt Ingenieurbüro GmbH

Krümke 1

D-38479 Tappenbeck

 

Telefon:+49 5366 9611-1845

Telefax: +49 5366 9611-1100 
 

Internet:http://www.bertrandt.com   

E-Mail:  mailto:carine.kemayounya...@de.bertrandt.com

 

Geschäftsführer: Ulrich Subklew

Sitz der Gesellschaft: Tappenbeck, Amtsgericht: Braunschweig, HRB 100280

 

The contents of this e-mail are confidential. If you are not the named 
addressee or if this transmission has been addressed to you in error, please 
notify the sender immediately and then delete this e-mail. Any unauthorized 
copying and transmission is forbidden. 
E-mail transmission cannot be guaranteed to be secure. If verification is 
required, please request a hard copy version. Please note, that incoming e-mail 
is not checked regularly. This may result in a failure to comply with legal or 
contractual terms. Therefore it is not sufficient, to send any legal or 
contractual declarations by e-mail. In no event will Bertrandt be liable to you 
or any third party for any direct, indirect, consequential, special or 
exemplary damages or lost profit resulting from this failure.

 

 

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

Re: [sqlite] Union all writting on /var/tmp

[Richard Hipp]

On Tue, Oct 30, 2012 at 7:39 AM, Eleytherios Stamatogiannakis <
est...@gmail.com> wrote:

>
> Mr. Hipp please excuse my attitude on my first email
>

All is forgotten.  Thank you for bringing this optimization opportunity to
our attention!

-- 
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] Union all writting on /var/tmp

[Eleytherios Stamatogiannakis]

Hello,

Mr. Hipp please excuse my attitude on my first email (the one your 
replied to). It came after 3 days of intense pressure to find out what 
the problem of machines coming to a crawl whenever a particular query 
with sufficiently large union-ed all tables was run.


Due to the quality of SQLite it literally was the last thing that i 
looked at. I even had prepared emails to other people asking them to 
look at their software, and to not to buffer on the hard disk so much.


Concerning your effort to fix it. I also suspected about the "path of 
least resistance", considering "union all". This is why in my next 
emails i mainly asked for a switch to change the "/var/tmp" path. The 
other thing that i've asked for, was for the documentation to have a 
warning about union all's behaviour. I believed that warning could save 
a lot of time and effort for other people that tripped on the same thing 
as me.


Thank you very very much for your fix. I'm glad that you put the 
considerable effort to it. My Phd was in databases, so i can understand 
how much effort this fix required. I have already downloaded the patch 
and i'll test it asap.


Due to me also working/having worked on Open Source software (madIS, 
Rigs of Rods), i realize your second point in my skin. Nevertheless 
sometimes, i also slide to this kind of behaviour. I'll try to be on 
guard against it in the future.


Best regards,

lefteris.

On 30/10/12 03:08, Richard Hipp wrote:



On Fri, Oct 26, 2012 at 2:16 PM, Eleytherios Stamatogiannakis
> wrote:

I have been observing the following freaky behaviour of SQLite. When
i run:

select count(*) from (select * from huge_table union all select *
from huge_table);

Sqlite starts writting in /var/tmp/ a file like:

  /var/tmp/etilqs___gblRd6vUPcx91Hl, the root partition of fills up
and an error is raised.

Why does SQLite 3.7.14.1 need to write at all when doing union all?
It seems to me that there is no reason for doing so.


The reason for using a temp table for UNION ALL in a subquery is because
that is the path of least resistance.  The same identical code can
handle UNION ALL, UNION, INTERSECT, EXCEPT and various other cases.
Some queries (such as your UNION ALL) can in fact do without the temp
table.  But those are special cases that have to coded separately.
Adding, testing, and maintaining that extra code involves a lot of
work.  And the extra code risks introducing bugs that might appear even
for people who are not doing a UNION ALL in a subquery.  And in over 12
years of use, in over a million different applications, with over 2
billion deployments, nobody has ever before requested this optimization.

At http://www.sqlite.org/src/info/7af3acbbd4 there is a patch that adds
the optimization to avoid using a temp table for your UNION ALL
queries.  This one small patch represents about 12 hours of intense
work, so far.  Much more work will be required to get the patch
performing to our release standards.  All of this effort on your behalf
you are receiving for free.  In return, we ask two things:

(1) Please download and test the patch and report any problems,
including performance problems.

(2) Please learn to be less grumpy, demanding, and condescending when
requesting help with software towards which you have contributed
nothing.  You have received this latest patch, and indeed all of SQLite,
by grace.  Therefore, please extend the same grace toward others.


Best regards,

lefteris.
_
sqlite-users mailing list
sqlite-users@sqlite.org 
http://sqlite.org:8080/cgi-__bin/mailman/listinfo/sqlite-__users





--
D. Richard Hipp
d...@sqlite.org 


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