Like in MySQL, using
SELECT SQL_CALC_FOUND_ROWS from tablename limit 10
And then using
SELECT FOUND_ROWS() as rows
to know the row count of the last executed query.
Is there any similar function/way in Snowflake from which I can find the count of rows of the previously executed query?
Note:- FOUND_ROWS() returns total count (ignoring limit clause). So I am looking for a solution which ignores the limit clause and returns the total count in snowflake
Note:- I don't want to use count(*)
Update
Adding brute force solution using count(*) from my side
$sql = select * from tablename limit 10;
using regex/any other approach I removed the limit part
So my query becomes
$sql_count = select * from tablename
Finally, execute the below query in snowflake and thus get my desire result
$res = select count(*) from ($sql_count)
Note:- I know this is not the standard way and also don't want this approach but for time being I using this in my project
You can use a combination of last_query_id() and a query on INFORMATION_SCHEMA.QUERY_HISTORY function.
Something like
select SQL_CALC_FOUND_ROWS from tablename limit 10;
select ROWS_PRODUCED
from table(information_schema.query_history())
where QUERY_ID=(last_query_id());
Related
I cannot get this type of select query (pseudo-code) to work. The UDF returns a table with 8 columns in a single row for a given 'UID_VEHICLE'. It works perfectly when the 'UID_VEHICLE' is provided as a constant like 3308. But I need one row of these function-results for each vehicle for a given customer -- up to 100 rows to be returned.
SELECT
*
FROM
[dbo].[fnGetNextDOT_InspectionData](UID_VEHICLE)
WHERE
UID_VEHICLE IN (SELECT UID_VEHICLE
FROM tVEHICLES
WHERE UID_CUSTOMER = 88);
Your comments and solutions are welcome...thanks...John
When passing row values from a query into a TVF, you need to use CROSS APPLY or OUTER APPLY (starting with SQL Server 2005):
SELECT * -- or dot.*, or whatever is desired
FROM tVEHICLES veh
CROSS APPLY [dbo].[fnGetNextDOT_InspectionData](veh.UID_VEHICLE) dot
WHERE veh.UID_CUSTOMER = 88;
I have a big query to get multiple rows by id's like
SELECT *
FROM TABLE
WHERE Id in (1001..10000)
This query runs very slow and it ends up with timeout exception.
Temp fix for it is querying with limit, break this query into 10 parts per 1000 id's.
I heard that using temp tables may help in this case but also looks like ms sql server automatically doing it underneath.
What is the best way to handle problems like this?
You could write the query as follows using a temporary table:
CREATE TABLE #ids(Id INT NOT NULL PRIMARY KEY);
INSERT INTO #ids(Id) VALUES (1001),(1002),/*add your individual Ids here*/,(10000);
SELECT
t.*
FROM
[Table] AS t
INNER JOIN #ids AS ids ON
ids.Id=t.Id;
DROP TABLE #ids;
My guess is that it will probably run faster than your original query. Lookup can be done directly using an index (if it exists on the [Table].Id column).
Your original query translates to
SELECT *
FROM [TABLE]
WHERE Id=1000 OR Id=1001 OR /*...*/ OR Id=10000;
This would require evalutation of the expression Id=1000 OR Id=1001 OR /*...*/ OR Id=10000 for every row in [Table] which probably takes longer than with a temporary table. The example with a temporary table takes each Id in #ids and looks for a corresponding Id in [Table] using an index.
This all assumes that there are gaps in the Ids between 1000 and 10000. Otherwise it would be easier to write
SELECT *
FROM [TABLE]
WHERE Id BETWEEN 1001 AND 10000;
This would also require an index on [Table].Id to speed it up.
Running the following query returns 4 rows. As I can see in SSMS the order of returned rows is the same as I specified in the IN clause.
SELECT * FROM Table WHERE ID IN (4,3,2,1)
Can I say that the order of returned rows are ALWAYS the same as they appear in the IN clause?
If yes then is it true, that the following two queries return the rows in the same order? (as I've tested the orders are the same, but I don't know if I can trust this behavior)
SELECT TOP 10 * FROM Table ORDER BY LastModification DESC
SELECT * FROM Table WHERE ID IN (SELECT TOP 10 ID FROM Table ORDER BY LastModification DESC)
I ask this question because I have a quite complex select query. Using this trick over it brings me ca. 30% performance gain, in my case.
You cannot guarantee the records to be in any particular order unless you use ORDER BY clause. You may use some tricks that may work some of the time but they won't give you guarantee of the order.
After reading this interesting article about intermediate materialization - I still have some questions.
I have this query :
SELECT *
FROM ...
WHERE isnumeric(MyCol)=1 and ( CAST( MyCol AS int)>1)
However, the where clause order is not deterministic.
So I might get exception here.( if he first tries to cast "k1k1" )
I assume this will solve the problem
SELECT MyCol
FROM
(SELECT TOP 100 PERCENT foo From MyTable WHERE ISNUMERIC (MyCol ) > 1 ORDER BY MyCol ) bar
WHERE
CAST(MyCol AS int) > 100
why does putting top 100 + order will change VS my regular query ?
I read in the comments :
(the "intermediate" result -- in other words, a result obtained during
the process, that will be used to calculate the final result) will be
physically stored ("materialized") in TempDB and used from there for
the remainder of the user, instead of being queried back from the base
tables.
what difference does it makes if it is stored in tempDB or queried back from the base tables? it is the same data !
The supported way to avoid errors due to the optimizer reorganizing things is to use CASE:
SELECT *
FROM YourTable
WHERE
1 <=
CASE
WHEN aa NOT LIKE '%[^0-9]%'
THEN CONVERT(int, aa)
ELSE 0
END;
Intermediate materialization is not a supported technique, so it should only be employed by very expert users in special circumstances where the risks are understood and accepted.
TOP 100 PERCENT is generally ignored by the optimizer in SQL Server 2005 onward.
By adding the TOP clause into the inner query, you're forcing SQL Server to run that query first before it runs the outer query - thereby discarding all rows for which ISNUMERIC returns false.
Without the TOP clause, the optimiser can rewrite the query to be the same as your first query.
I have written query, I wanted to know the effect of usage of IN clause in Query.
Query I
Select * from khatapayment_track
Where Property_ID IN (Select Property_id from khata_header where DIV_ID=2)
Query II
Select * from khatapayment_track KPT, khata_header KH
Where kh.Property_id=KPT.Property_id and KH.DIV_Id=2
I would like to know
1) which one is faster
2) Any effects of using IN clause, is it advisable to use if a query has a 3 IN clause.
Can you please help me with examples
Your second query is faster, but it is better to use joins (it looks nicer and it have the same execution plan):
select
*
from
khatapayment_track t
inner join khata_header h on (h.property_id = t.property_id)
where
h.div_id = 2
Also you can use mysql profiler to compare your queries.
Query II is faster in your example as you are using subquery in Query I.
but consider follwing example which returns similar o/p but query i will returns faster
select * from tableName where id in (1,2,3,4)
is similar to
select * from tableName where id =1 OR id =2 OR id =3 Or id =4