Re: [sqlite] SIMD based JSON parsing for speeding up JSON extension

> It's only a fair comparison if the simdjson code runs on the same system. > It might reach 10GB/s or 200MB/s… > > Another possible concern is whether the SQLite JSON code is 100% compliant AFAIK no known json parser is 100% compliant. > (I don't know if this is the case). There are some

Re: [sqlite] SIMD based JSON parsing for speeding up JSON extension

It's only a fair comparison if the simdjson code runs on the same system. It might reach 10GB/s or 200MB/s… Another possible concern is whether the SQLite JSON code is 100% compliant (I don't know if this is the case). There are some hairy edge cases in JSON (Unicode handling) that might slow

Re: [sqlite] SIMD based JSON parsing for speeding up JSON extension

On 2/25/19, Richard Hipp wrote: > performance of just over 3GB/sec, which is slightly > faster than reported simdjson performance of 2.9GB/sec. Further analysis shows that SQLite was caching its parse tree, which was distorting the measurement. The following script adds a different string of

Re: [sqlite] SIMD based JSON parsing for speeding up JSON extension

On 2/25/19, Robert M. Münch wrote: > Hi, see: https://github.com/lemire/simdjson > > Can parse GB/s of JSON input. This might be a good candidate to use in the > extension. Thanks for the link. I downloaded one of the sample input files "gsoc-2018.json" and then ran the following test case

Re: [sqlite] Bug report: Data race in pcache1.c

Hi Richard, thanks a million for your check-in! It indeed fixed our issues with TSan! Best regards, Jan On Wed, Jan 9, 2019 at 3:55 PM Richard Hipp wrote: > Check-in https://www.sqlite.org/src/info/383437be276719ac will perhaps > silence the harmless false-positives reported by TSAN. Please

[sqlite] SIMD based JSON parsing for speeding up JSON extension

Hi, see: https://github.com/lemire/simdjson Can parse GB/s of JSON input. This might be a good candidate to use in the extension. -- Robert M. Münch signature.asc Description: OpenPGP digital signature ___ sqlite-users mailing list

Re: [sqlite] Foreign Key constraint fails due to unrelated field

On Monday, 25 February, 2019 05:43, Jonathan Moules wrote: >CREATE TABLE error_codes ( > error_code INTEGER PRIMARY KEY >UNIQUE, > error TEXT >); You do not need (and should not) specify BOTH "PRIMARY KEY" and "UNIQUE". Both are enforced with a unique

Re: [sqlite] fyi, suspected typos in documentation: https://sqlite.org/c3ref/total_changes.html

Re: "If you think my fix is incorrect" Heavens no, just drawing attention to it to be sure it was as you intended. FWIW, the fix looks good to me. > > ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] BigInt loss accuracy

Your method of storing works fine, but Pandas looks like it's doing something weird to your results. When I run this without pandas my output lines don't start until 17, which is the first row things start getting stored as and returned as floats, and matches up perfectly as the first row over

Re: [sqlite] fyi, suspected typos in documentation: https://sqlite.org/c3ref/total_changes.html

This is the fix I'm going with: https://www.sqlite.org/src/info/4febdfb37b475361 If you think my fix is incorrect, please let me know promptly because we are about to release 3.27.2 that includes this fix. On 2/25/19, Simon Slavin wrote: > On 25 Feb 2019, at 2:12pm, Donald Griggs wrote: > >>

Re: [sqlite] fyi, suspected typos in documentation: https://sqlite.org/c3ref/total_changes.html

On 25 Feb 2019, at 2:12pm, Donald Griggs wrote: > https://sqlite.org/c3ref/total_changes.html > > This the sqlite3_total_changes(D) interface only reports the number of rows > that changed due to SQL statement ... > > Perhaps should be: > [[Thus]] the sqlite3_total_changes(D) interface only

Re: [sqlite] Foreign Key constraint fails due to unrelated field

Thanks Clemens, that was it (the comma). That was a mildly embarrassing oversight. Thanks again, Jonathan On 2019-02-25 12:52, Clemens Ladisch wrote: Jonathan Moules wrote: UPDATE lookups set error_code=3 and exp_content_type='ogc_except' WHERE content_hash = '0027f2c9b80002a6'; This

[sqlite] fyi, suspected typos in documentation: https://sqlite.org/c3ref/total_changes.html

https://sqlite.org/c3ref/total_changes.html This the sqlite3_total_changes(D) interface only reports the number of rows that changed due to SQL statement ... Perhaps should be: [[Thus]] the sqlite3_total_changes(D) interface only reports the number of rows that changed due to [[an]] SQL

Re: [sqlite] SQLite3's vulnerability in 3.27.1 and 3.26

I was able to reproduce this behaviour using much shorter query (in sqlite.exe 3.27.1): SELECT + sum(0) OVER() ORDER BY + sum(0) OVER(); SELECT + avg(0) OVER() ORDER BY + avg(0) OVER(); SELECT 1 + avg(0) OVER() ORDER BY 1 + avg(0) OVER(); SELECT - - - - - avg(0) OVER()

Re: [sqlite] Foreign Key constraint fails due to unrelated field

Jonathan Moules wrote: > UPDATE lookups set error_code=3 and exp_content_type='ogc_except' WHERE > content_hash = '0027f2c9b80002a6'; This fails because "3 and exp_content_type='ogc_except'" is interpreted as a boolean expression. To update multiple fields, separate them with commas: UPDATE

[sqlite] Foreign Key constraint fails due to unrelated field

Hi List, I'm seeing some oddness with Foreign Keys and was wondering what was going on. A few days ago I did a refactor of my error codes, changing the numbers to be more logically consistent with groupings. They're in a separate table table which is referenced from a lookups table. This was

Re: [sqlite] Speed: geopoly_overlap() or geopoly_within() VS. using R*Tree directly?

On 2/25/19, Robert M. Münch wrote: > Hi, when doing 2D hit-testing with only rectangular areas, is it faster to > use the geopoly extension and functions or is the bare R*Tree extension > faster? My guess would be bare R*Tree extension, but I have not run the experiment. -- D. Richard Hipp

[sqlite] Speed: geopoly_overlap() or geopoly_within() VS. using R*Tree directly?

Hi, when doing 2D hit-testing with only rectangular areas, is it faster to use the geopoly extension and functions or is the bare R*Tree extension faster? -- Robert M. Münch signature.asc Description: OpenPGP digital signature ___ sqlite-users