On 28 Jul 2015, at 8:25pm, rotaiv wrote:
> From what I read, it was recommended to create indexes for any field used
> in the SELECT statement. Is that correct? Give my original query:
>
> SELECT home.fpath
> FROM home
> LEFT JOIN work ON work.fpath = home.fpath
> WHERE work.fpath IS NULL
>
On 28 Jul 2015, at 7:55pm, rotaiv wrote:
> That is the machine. Originally. it was taking 40+ minutes. I upgraded to
> the latest version and it decreased to 16 seconds. With indexes, 5
> seconds. :-D
Ah, okay I get it. In that case the index would probably have given you a time
of 5
On 28 Jul 2015, at 7:43pm, rotaiv wrote:
> I create indexes and my original query time dropped from 16 seconds to this:
>
> real 0m5.928s
> user 0m5.361s
> sys 0m0.565s
Is it worth checking on the machine you originally reported 40+ minutes for ?
That one should be considerably faster.
On 28.07.2015 18:52, Richard Hipp wrote:
> I get the correct answer (2147483647 2147483649 2147483649) when I try
> this on 64-bit Ubuntu.
Yes, I've just tested it on Debian x64 and it works too, but I noticed
that $l3 is stored as int, not as wideInt like on Windows:
%
Hi,
I'm using sqlite3 TCL extension from Teapot (version 64-bit). When I try
to insert number bigger than signed 32-bit it inserts wrong number to
database.
Same code run with 32-bit version works fine.
Example in TCL console illustrating this issue:
% info patchlevel
8.6.4
% package require
Updating to sqlite3.c 3.8.11
The RELEASE target for CE6.0/CE7.0 don't build (Internal Compiler Error).
1>Internal Compiler Error in c:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\ce\bin\x86_arm\cl.exe. You will be prompted to send an error report to
Microsoft later.
1>Project : error
Not quite. The older version brought it down to 8 seconds (as compared to
5 seconds) but still a whole lot better than 40+ minutes.
It is very interesting to see an index can make such a remarkable
difference in that particular scenario. This is my first time creating
indexes but I will
That is the machine. Originally. it was taking 40+ minutes. I upgraded to
the latest version and it decreased to 16 seconds. With indexes, 5
seconds. :-D
On Tue, Jul 28, 2015 at 2:53 PM, Simon Slavin wrote:
>
> On 28 Jul 2015, at 7:43pm, rotaiv wrote:
>
> > I create indexes and my original
I create indexes and my original query time dropped from 16 seconds to this:
real 0m5.928s
user 0m5.361s
sys 0m0.565s
However, when I use the query you suggested, it was a little slower:
real 0m9.827s
user 0m8.952s
sys 0m0.873s
On Mon, Jul 27, 2015 at 5:38 PM, Keith Medcalf wrote:
>
On 7/28/15, Rafa? Ponikwia wrote:
> Hi,
> I'm using sqlite3 TCL extension from Teapot (version 64-bit). When I try
> to insert number bigger than signed 32-bit it inserts wrong number to
> database.
>> % db eval {
> CREATE TABLE test (num NUMERIC);
> INSERT INTO test (num) VALUES ($l1),
I was testing a custom SQLite with the test files and one of the
file(tclsqlite.test) gave a segmentation fault, when I used Valgrind, it
didn't give any stack trace but instead gave the following error.
==5697==
==5697== Process terminating with default action of signal 11 (SIGSEGV):
dumping
On 28 Jul 2015, at 9:55am, Paolo Bolzoni
wrote:
> From the C interface, the way to decide the directory is setting the
> value of sqlite3_temp_directory char pointer. As explained here:
> https://www.sqlite.org/c3ref/temp_directory.html
> This is also the first place sqlite3 checks.
The
On 28 Jul 2015, at 10:49am, Paolo Bolzoni
wrote:
> I guess it is not really a problem, but it means that a part of the
> deprecated pragma there is no fully portable way?
There cannot be a fully portable way, because path specifications are not
portable. For instance, "C:\temp" means
I guess it is not really a problem, but it means that a part of the
deprecated pragma there is no fully portable way?
On Tue, Jul 28, 2015 at 10:56 AM, Clemens Ladisch wrote:
> Simon Slavin wrote:
>> both platforms use whatever the expected variable name was for that OS.
>
> Unix:
> 1. #pragma
Simon Slavin wrote:
> both platforms use whatever the expected variable name was for that OS.
Unix:
1. #pragma temp_store_directory
2. getenv("SQLITE_TMPDIR")
3. getenv("TMPDIR")
4. /var/tmp
5. /usr/tmp
6. /tmp
Cygwin:
1. #pragma temp_store_directory
2. getenv("SQLITE_TMPDIR")
3.
So, just be sure we are in the same page:
>From the C interface, the way to decide the directory is setting the
value of sqlite3_temp_directory char pointer. As explained here:
https://www.sqlite.org/c3ref/temp_directory.html
This is also the first place sqlite3 checks.
>From anywhere else
On 07/28/2015 02:55 AM, Hinrichsen, John wrote:
> Hi,
>
> I was not able to get the fts5 module to build from the versioned source
> tarball for this release (http://www.sqlite.org/2015/sqlite-src-3081100.zip
> ).
Which step failed?
>
> I was able to 'make fts5.c' following the instructions
On Mon, Jul 27, 2015 at 9:35 PM, Simon Slavin wrote:
> On 27 Jul 2015, at 8:03pm, Zsb?n Ambrus wrote:
> I tried this once a couple of years ago, and both platforms use whatever the
> expected variable name was for that OS. In other words, a native programmer
> to that OS would get whatever
18 matches
Mail list logo
