Thank you Keith for the detail explanation.
I misunderstood the 2 replies were opposite but this is not the case.
Thank you again
Jean-bapstiste
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/ma
On Wednesday, 15 January, 2020 02:06, Jean-Baptiste Gardette
wrote:
> Just to be sure, is it unsafe to write a non agregate SELECT with GROUP
> BY and HAVING clauses (without sub-SELECT) for the sole prupose
> explained before (even if the approache is discutable) ?
Presently, yes it is.
>I
Just to be sure, is it unsafe to write a non agregate SELECT with GROUP
BY and HAVING clauses (without sub-SELECT)
for the sole prupose explained before (even if the approache is
discutable) ?
I understand 2 different answers here :
- "No, this kind of query can't be rewritten by the optimizer
On 1/14/20, Keith Medcalf wrote:
>
> I seem to recall something about "expensive" conditions that will be forced
> to be run on only as few surviving candidate rows as possible, but my
> recollection is vague (they say the memory is the second thing to go --
> strange I can't remember the first).
On Tuesday, 14 January, 2020 09:23, Simon Slavin wrote:
>Would it be possible to phrase your SELECT as a SELECT with a sub-SELECT
>? Have the sub-SELECT figure out which rows you want in which order,
>then use a SELECT to apply your UDF to them ? It is guaranteed that the
>sub-SELECT is proces
On 14 Jan 2020, at 4:14pm, Jean-Baptiste Gardette wrote:
> The reason i asked this is that i have a query in wich one condition
> filtering the recordset involves
> an UDF and this UDF needs to be processed after all table filters have been
> applied
You cannot guarantee this. And even if you
Thank you Dominic and Keith for your replies
The reason i asked this is that i have a query in wich one condition
filtering the recordset involves
an UDF and this UDF needs to be processed after all table filters have
been applied
Illustration :
additionnal table :
CREATE TABLE t2 (
a TEXT
On Tuesday, 14 January, 2020 06:58, Jean-Baptiste Gardette
wrote:
>Consider the following exemple :
>CREATE TABLE t1 (
>a TEXT PRIMARY KEY,
>b INTEGER);
>SELECT *
>FROM t1
>GROUP BY a
>HAVING b > 1;
>Will the GROUP BY clause be supressed and HAVING clause be rewritten in
>WHERE clause by the
On Tue, Jan 14, 2020 at 2:57 PM Jean-Baptiste Gardette
wrote:
> SELECT * FROM t1 GROUP BY a HAVING b > 1;
>
> Will the GROUP BY clause be supressed and HAVING clause be rewritten in WHERE
> clause by the optimizer ?
My question would be why you wouldn't write it as a WHERE clause in
the first pl
Hi,
Consider the following exemple :
CREATE TABLE t1 (
a TEXT PRIMARY KEY,
b INTEGER);
SELECT *
FROM t1
GROUP BY a
HAVING b > 1;
Will the GROUP BY clause be supressed and HAVING clause be rewritten in
WHERE clause by the optimizer ?
Jean-Baptiste
_
10 matches
Mail list logo
