Re: [sqlite] Need advice on using nested selects in JOIN statements as a logical 'AND'

2013-11-27 Thread Tristan Van Berkom
On Thu, 2013-11-28 at 00:20 -0500, Igor Tandetnik wrote: > On 11/27/2013 11:52 PM, Tristan Van Berkom wrote: > > > > SELECT DISTINCT summary.uid, summary.vcard FROM 'folder_id' AS summary > > LEFT OUTER JOIN 'folder_id_phone_list' AS phone_list > >

Re: [sqlite] Need advice on using nested selects in JOIN statements as a logical 'AND'

2013-11-27 Thread Tristan Van Berkom
On Thu, 2013-11-28 at 00:20 -0500, Igor Tandetnik wrote: > On 11/27/2013 11:52 PM, Tristan Van Berkom wrote: > > > > SELECT DISTINCT summary.uid, summary.vcard FROM 'folder_id' AS summary > > LEFT OUTER JOIN 'folder_id_phone_list' AS phone_list > >

Re: [sqlite] Need advice on using nested selects in JOIN statements as a logical 'AND'

2013-11-27 Thread Igor Tandetnik
On 11/27/2013 11:52 PM, Tristan Van Berkom wrote: SELECT DISTINCT summary.uid, summary.vcard FROM 'folder_id' AS summary LEFT OUTER JOIN 'folder_id_phone_list' AS phone_list ON phone_list.uid = summary.uid LEFT OUTER JOIN

[sqlite] Need advice on using nested selects in JOIN statements as a logical 'AND'

2013-11-27 Thread Tristan Van Berkom
Hi, I don't have many years experience with the SQL language and I've cooked up some pretty complex stuff which will run in production environments, I just want to confirm with you that the assumptions I've made are true (I do have a lot of unit tests which confirm that my code works as far as

[sqlite] [ANNOUNCEMENT] Updated: sqlite3-3.8.2-1 (beta, as test package) for Cygwin/Cygwin64

2013-11-27 Thread Jan Nijtmans
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine Changes since 3.8.1-1 = * Updated to upstream 3.8.2 beta release. Main feature: * Added support for WITHOUT ROWID tables. * The path handing in

Re: [sqlite] Visual Studio 2013 Issue - GetVersionEx deprecated

2013-11-27 Thread Jan Nijtmans
2013/11/4 Jan Nijtmans: > 2013/11/4 Simon Slavin: >> On 4 Nov 2013, at 6:32am, David de Regt wrote: >>> In Visual Studio 2013, which uses the Windows 8.1 Platform SDK, they've >>> marked GetVersionEx as deprecated, trying to supercede it through to >>> VerifyVersionInfo and

Re: [sqlite] Failed test on aarch64

2013-11-27 Thread Dan Kennedy
On 11/27/2013 04:26 PM, Zsbán Ambrus wrote: On Tue, Nov 26, 2013 at 5:01 PM, Richard Hipp wrote: The check-in above changes the behavior of REAL-to-INTEGER casts where the REAL value is larger than the largest possible integer. For example: SELECT

Re: [sqlite] Failed test on aarch64

2013-11-27 Thread Zsbán Ambrus
On Tue, Nov 26, 2013 at 5:01 PM, Richard Hipp wrote: > The check-in above changes the behavior of REAL-to-INTEGER casts where the > REAL value is larger than the largest possible integer. For example: > > SELECT CAST(9223372036854775808.0 to INTEGER); > > The change causes

Re: [sqlite] SQLite version 3.8.2 running 2.5x faster for some queries.

2013-11-27 Thread Luuk
On 27-11-2013 03:55, James K. Lowden wrote: On Mon, 25 Nov 2013 19:44:15 +0100 Luuk wrote: On 25-11-2013 13:41, Simon Slavin wrote: I'm wondering whether there's an argument that it should be evaluated just once for a transaction. I'm still thinking about this question,

Re: [sqlite] count (*) performance

2013-11-27 Thread Hick Gunter
It calls the xBestIndex method instead. However, the virtual table module cannot determine which (if any) fields will be selected and must act solely upon the passed constraints. Unless you are willing to implement a virtual field and write something like "SELECT FROM vtable WHERE AND

Re: [sqlite] count (*) performance

2013-11-27 Thread Dominique Devienne
On Wed, Nov 27, 2013 at 9:35 AM, Clemens Ladisch wrote: > veeresh kumar wrote: > > I see that in release history for 3.8.1 below item. > > "Estimate the sizes of table and index rows and use the smallest > applicable B-Tree for full scans and "count(*)" operations." > > > >

Re: [sqlite] count (*) performance

2013-11-27 Thread Clemens Ladisch
veeresh kumar wrote: > I see that in release history for 3.8.1 below item. > "Estimate the sizes of table and index rows and use the smallest applicable > B-Tree for full scans and "count(*)" operations." > > Does it mean that performance of count(*) has been improved in 3.8.1 Yes. > and if yes