[sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

2020-01-04 Thread Keith Medcalf
Hrm. Inconsistent/incorrect results. Consider: create table a(id integer primary key, a); insert into a values (1,1), (2,1), (3,1); create table b(id integer primary key, b); insert into b values (1,2), (3,2), (4,2); create table c(id integer primary key, c); insert into c values (1,3), (4,3),

Re: [sqlite] SQLite command-line result is different from Perl DBI::Sqlite result

2020-01-04 Thread Keith Medcalf
-- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. On Saturday, 4 January, 2020 18:31, Amer Neely wrote: >I'm fairly new to SQLite, but have been using MySQL / mariadb in a local >and web-based environment for several

Re: [sqlite] SQLite command-line result is different from Perl DBI::Sqlite result

2020-01-04 Thread Igor Korot
Hi, On Sat, Jan 4, 2020 at 7:31 PM Amer Neely wrote: > > Hello all, > I'm fairly new to SQLite, but have been using MySQL / mariadb in a local > and web-based environment for several years. So far I'm happy and > impressed with SQLite, but I recently noticed some odd behaviour with > one of my

[sqlite] SQLite command-line result is different from Perl DBI::Sqlite result

2020-01-04 Thread Amer Neely
Hello all, I'm fairly new to SQLite, but have been using MySQL / mariadb in a local and web-based environment for several years. So far I'm happy and impressed with SQLite, but I recently noticed some odd behaviour with one of my queries. Using the command-line in a shell (Mac High Sierra) I get a

[sqlite] Performance

2020-01-04 Thread Keith Medcalf
So here is another (this time real world) example using program I wrote which runs ~11 million initial connection packets against ~1800 firewall rules. It is written in Python and is inherently single-threaded. The only multithreading is SQLite3's internal threaded sorting. SINGLETHREAD

Re: [sqlite] Upgrading from version 3.6.16 to 3.30.1

2020-01-04 Thread Warren Young
On Jan 4, 2020, at 12:49 PM, Gerry Snyder wrote: > > On Fri, Jan 3, 2020 at 10:57 AM Richard Watt wrote: > >> Does anyone know of any potential issues I might encounter and how to >> correct them please? >> > Few packages are maintained with more care about backward compatibility > than

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

2020-01-04 Thread Keith Medcalf
Well, actually, no. It was a single process that spins up 64 threads each of which accesses its own per-thread in-memory database using an in-that-thread-only-in-thread-database-connection-in-that-thread. Making some simple modifications (changing the number of threads to 6 and the

Re: [sqlite] Upgrading from version 3.6.16 to 3.30.1

2020-01-04 Thread J. King
On January 3, 2020 12:57:14 p.m. EST, Richard Watt wrote: >I'm currently updating a C# .NET application that uses SQLite 3.6.16 to >run under a new Siemens Sinumerik version and I'd also like to update >it >to use the latest SQLite, which is 3.30.1. > >Does anyone know of any potential issues I

Re: [sqlite] Upgrading from version 3.6.16 to 3.30.1

2020-01-04 Thread Gerry Snyder
On Fri, Jan 3, 2020 at 10:57 AM Richard Watt wrote: > I'm currently updating a C# .NET application that uses SQLite 3.6.16 to > run under a new Siemens Sinumerik version and I'd also like to update it > to use the latest SQLite, which is 3.30.1. > > Does anyone know of any potential issues I

Re: [sqlite] Questions about your "Performance Matters" talk re SQLite

2020-01-04 Thread Simon Slavin
On 4 Jan 2020, at 5:49pm, Doug wrote: > for (i=1000; i--; i>0); If you have optimization turned on, your compiler might turn that into "i = 0". Optimization messes with a lot of benchmarks. Checking which optimization setting was used is one aspect of what Howard Chu was talking about:

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

2020-01-04 Thread Doug
> -Original Message- > From: sqlite-users > On Behalf Of J Decker > Sent: Saturday, January 04, 2020 4:11 AM > > Could wish there was a way to > pause execution without giving up execution context... What about? for (i=1000; i--; i>0); ___

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

2020-01-04 Thread Doug
Thanks, Jens. I got it. The benchmark sounds like it isn't a real benchmark, but a made-up scenario to exercise the Coz code. I've let go now. Doug > -Original Message- > From: sqlite-users > On Behalf Of Jens Alfke > Sent: Friday, January 03, 2020 10:58 PM > To: SQLite mailing list >

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

2020-01-04 Thread J Decker
On Sat, Jan 4, 2020 at 2:59 AM Howard Chu wrote: > Keith Medcalf wrote: > > > > Indeed turning off memstatus leads to a 500% (from ~3s to ~0.5s) > performance increase. > > Changing the threading mode or the indirection level of the mutexes > calls seems to have no significant effect. > > > Goes

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

2020-01-04 Thread Howard Chu
Keith Medcalf wrote: > > Indeed turning off memstatus leads to a 500% (from ~3s to ~0.5s) performance > increase. > Changing the threading mode or the indirection level of the mutexes calls > seems to have no significant effect. > Goes to show - publishing benchmark results without

Re: [sqlite] Question about passwords in System.Data.Sqlite

2020-01-04 Thread Warren Young
On Jan 4, 2020, at 12:23 AM, Mike King wrote: > > This is the subject: > > Hex Password with System.Data.Sqlite (.Net Core) My Python-fu sucks, but I don’t think that can match the administrivia rule: https://gitlab.com/mailman/mailman/blob/master/src/mailman/rules/administrivia.py It