For tracked SQL function, hasura query is taking a lot of time but when it is executed from SQL directly it takes only few milliseconds to get the data. We are not able to figure out what is the actual problem as we are using Postgresql DB
We followed some steps to reduce the response time
Applying indexes on DB
Analysing the query plan to reduce the cost
Querying only a limited set of data to reduce the response size
We tried to run that query from SQL directly which only took few milliseconds but when when try to run from hasura query it took a lot of time for same parameters
I suspect that it is probably due to permissions that are being evaluated when you run the function through Hasura.
When you were analysing the query plan, did you also make sure that you were passing in roles to ensure that the plan captures any additional changes to the query that are required in order for the permissions to be evaluated?
Related
My query takes about 3-5 seconds to run. When I run the report, a simple summary of a few columns it takes 25-30 minutes!! It is a Group Left report. I've tried playing around with the query, and I've tried handling the grouping in the query with no luck. Any ideas what might be causing this?
Is the query being executed within a stored procedure? If yes try executing the SQL without passing the variables through an SQL stored procedure.
If there is a difference in time it takes to execute, try some optimizations like for example removing parameter sniffing (create local variables from within the stored procedure which contain copies of the variable values being passed through the stored procedure). These can give you an indication if the query requires optimization.
In my experience, sometimes queries that return a lot of data will appear to run fast from a tool like Toad or SQL Developer, but when you try to get all the rows, then you hit the real overall performance of the query.
So perhaps your query returns a lot of rows and all that time is spending doing all the i/o.
Our application issues an NHibernate-generated SQL query. At application runtime, the query takes about 12 seconds to run against a SQL Server database. SQL Profiler shows over 500,000 reads.
However, if I capture the exact query text using SQL Profiler, and run it again from SQL Studio, it takes 5 seconds and shows less than 4,600 reads.
The query uses a couple of parameters whose values are supplied at the end of the SQL text, and I'd read a little about parameter sniffing and inefficient query plans, but I had thought that related to stored procedures. Maybe NHibernate holds the resultset open while it instantiates its entities, which could explain the longer duration, but what could explain the extra 494,000 "reads" for the same query as performed by NHibernate? (No additional queries appear in the SQL Profiler trace.)
The query is specified as a LINQ query using NHibernate 3.1's LINQ facility. I didn't include the query itself because it seems like a basic question of philosophy: what could explain such a dramatic difference?
In case it's pertinent, there also happens to be a varbinary(max) column in the results, but in our situation it always contains null.
Any insight is much appreciated!
Be sure to read: http://www.sommarskog.se/query-plan-mysteries.html
Same rules apply for procs and sp_executesql. A huge reason for shoddy plans can be passing in a nvarchar param for a varchar field, it causes index scans as opposed to seeks.
I very much doubt the output is affecting the perf here, it is likely to be an issue with one of the params sent in, or selectivity of underlying tables.
When testing your output from profiler, be sure to include sp_executesql and make sure your settings match (stuff like SET ARITHABORT), otherwise you will cause a new plan to be generated.
You can always dig up the shoddy plan from the execution cache via sys.dm_exec_query_stats
The first query run on a large dataset on a Firebird database after starting our application is always very slow. Subsequent calls to the same query (it is a stored procedure) are fine. I assume that this is to do with something being loaded into memory but I could do with a explanation of what and whether there is anything that can be done to get around the issue.
If is a stored procedure the first query it compiles the stored procedure also it fetches the buffers and caches the result.
On the second query the procedure is not compiled again (precached) and the results are instant (the fetches are also in memory for some operating systems so no need for disk io)
one way is to optimize the sp or the tables
How larger are they? (number of records for each table)
one simple way to optimize this is to put a cron script that will run once per day/hour to prefill the caches so you will get fast sp
Maybe it's not about the query, but the connection time (delay) is long? There was such a problem with [old] Firebird/Interbase engines.
You didn't explain which Firebird version you are using but, in version 2.50, there is a bug (CORE 3227 - slow compilation of stored procedures) that can be the cause of your problem. More details:
http://www.firebirdnews.org/?p=5282&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+FirebirdNews+%28Firebird+News%29
I know, from whatever I've read, prepared statements are faster since pre-compiled cached version is used for recurring queries. My doubt is : Exactly where time is saved? I see, only the time taken in preparing a query could be saved. Even prepared statements have to do database search and so no time is saved there. Am I wrong?
That's correct. The time saved by using prepared statements is generally in the database engine planning/compiling the query.
The part of a "prepared query" that is prepared is the execution plan. The plan tells the database how to execute the query; which indexes to use, in which order. The execution plan also resolves any access rights.
Time is saved by building the execution plan once instead of for every query.
I'm trying to optimize a SQL Server. I have some experience with Mysql and one of the things that usually help is to enable query cache, that will basically cache query results as long as you are running the same query.
Is there something similar to this on SQL Server? Could you please point what is the name of this feature?
Thanks!
SQL Server doesn't cache result sets per se, but it does cache data pages which have been read, in addition to caching query execution plans. This means that if it has to read the same data pages again to answer a query, it will be faster since there are fewer physical reads (from disk) but you should still see the same amount of logical reads.
Here is an article with more details.
SQL Server will cache query results, but it's a little more complicated than in MySQL's case (since SQL Server provides ACID guarantees that MySQL does not - at least, not with MyISAM). But you'll definitely find that the second time you execute a query on SQL Server, it'll be faster than the first time (as long as no other changes have happened).
There's no specific name for this feature, that I'm aware of. It's more a combination of caches...