Keith, this definitely explains the observed time as it is relative to
count(a)*count (ab)**2, thus non-linear.
And a correlated sub-query is generally recalculated for each row.
But I do not agree with everything.
In my example it is correlated to the outermost query, and not to the
ist
> Subject: [sqlite] Slow query, with correlated sub-sub-query
>
> Hello, below is a theoretical query that becomes slow when the number
> of rows increases. What it does is:
> - scan input cases in table a
> - for each input case:
> -- determine the smallest value of at
: [sqlite] Slow query, with correlated sub-sub-query
Thanks David for the alernative solution, that is 500 times faster or
any times faster depending on the number of rows. I hope this does not
derive attention from my point that the original construction is not
very well delt with.
It was only
Thanks David for the alernative solution, that is 500 times faster or
any times faster depending on the number of rows. I hope this does not
derive attention from my point that the original construction is not
very well delt with.
It was only a theoretical query derived from a more complex
s-boun...@mailinglists.sqlite.org] On
Behalf Of E.Pasma
Sent: Friday, July 07, 2017 9:47 AM
To: SQLite mailing list
Subject: [sqlite] Slow query, with correlated sub-sub-query
Hello, below is a theoretical query that becomes slow when the number
of rows increases. What it does is:
- scan input
Hello, below is a theoretical query that becomes slow when the number
of rows increases. What it does is:
- scan input cases in table a
- for each input case:
-- determine the smallest value of attribute size of elements in table
ab
-- count the number of elements having this smallest size
6 matches
Mail list logo
