On 08/02/17 11:41, Cecil Westerhof wrote:
> OK, glad to help. What should I do?
It is nicest if whatever software/tools you already have also has some
sort of testing (ideally automated, but a manual checklist works too).
Then run the testing with the existing version of SQLite, and repeat
with
This wasn't a prepare and execute.
Prepare and execute takes some 5 seconds on my machine.
What I saw took 1.4 secs.
I think there must have been other overhead and this wasn't just a prepare.
Will check.
RBS
On Thu, Feb 9, 2017 at 10:13 AM, Richard Hipp wrote:
> On 2/9/17,
On 2/9/17, Bart Smissaert wrote:
> I have seen a prepare take over a second.
> Take for example this recursive Sudoku SQL:
>
I think you are confusing "prepare" with "prepare and execute". The
prepare for the SQL query you provided takes less than 60 microseconds
on my
I have seen a prepare take over a second.
Take for example this recursive Sudoku SQL:
WITH RECURSIVE
input(sud) AS (
VALUES('.3..76..1.5986.8...6...34..8.3..17...2...6.6284.9..58..7.')
),
digits(z, lp) AS (
VALUES('1', 1)
UNION ALL SELECT
CAST(lp+1 AS
On 2017/02/09 2:55 AM, James K. Lowden wrote:
some complicated statements can take minutes to simply prepare on a
large DB
I doubt that. I've never seen it, and I see no reason it should be
true. A huge SQL query might be 1000 tokens. Why should preparing it
take 1 second, let alone
Hi Jan,
Thanks for trying out my patch, and for your improvement. If I may suggest one
thing: change the 'for alignment' comments to something more informative, e.g.,
'please keep this line for SQLITE_ENABLE_UPDATE_DELETE_LIMIT debugging'.
I also toyed with the idea of running lemon with '-l'
Thanks for the replies. My own pre-prepare parser makes use of the
sqlite3GetToken and sqlite3KeywordCode functions although that requires some
minor changes to the sqlite3.c and .h files to make them accessible.
Subsequently the text is sent to a CheckSQL function that returns true or false
7 matches
Mail list logo