Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
In SQL Server while writing a query, I noticed that the data in inner query which is a derived table when joined with another table is taking long. The keys joined to the outer table is on the primary key. So I was surprised since the data was about 10,000 records and 15 columns.
But if we store the data from derived table in a temp table and then join the performance was less than 2 seconds. It made me wonder what the reason would be ?
First, you should edit your question and show your query . . . or at least the structure of the query.
Your issue is probably due to optimization of the query. When you create a temporary table, then the resulting query has accurate statistics about the table during the compilation phase.
When you use a derived table, SQL Server has to guess at the size of the intermediate table and decide on an execution plan before knowing the actual. This would appear to be a situation where the guess is wrong.
If you don't want to use a temporary table, you can probably get the same effect using hints, probably for the join to use either a hash or merge sort algorithm (in my experience, the nested loops algorithm is usually the cause of poor performance).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have been given an 800 lines SQL Query which is taking around 20 hours to fetch around 400 million records.
There are 13 tables which are partitioned by month.
The tables have records ranging from 10k to 400 million in each partition.
The tables are indexed on primary keys.
The query uses many inline views and outer joins and a few group by functions.
DBAs say we cannot add more indexes as it would slow down the performance since it is an OLTP system.
I have been asked to convert the query logic to pl/sql and then populate a table in chunks.Then do a select * from that table.
My end result should be a query which can be fed to my application.
So even after I use pl/sql to populate a table in chunks,ultimately I need to fetch the data from that table as a query.
My question is, since pl/sql would require select and insert both, are there any chances pl/sql can be faster than sql?
Are there any cases where pl/sql is faster for any result which is achievable by sql?
I will be happy to provide more information if the given info doesn't suffice.
Implementing it as a stored procedure could be faster because the SQL will already be parsed and compiled when the procedure is created. However, given the volume of data you are describing its unclear if this will make a significant difference. All you can do is try it and see.
I think you really need to identify where the performance problem is; where the time is being spent. For example (and I have seen examples of this many times), the majority of the time might be in fetching to 400M rows to whatever the "client" is. In that case, re-writing the query or as PL/SQL will make no difference.
Anyway, once you can enumerate the problem, you have a better chance of getting sound answers, rather than guesses...
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
SO i Have a query which, due to my database requires a lot of tables to function. Unfortunately, this is an older database, which is a little problematic to navigate.
This query, originally checked whether a Membership was to be 40 or 50 years in length which was easily solved. However, Now I have to see whether a an attribute telling me whether they are reinstated members which would invalidate this timeline is present.
I have managed to get show and exclude records, but the the error I believe I have made, is in using an outer join as I was attempting to check multiple records in the joined table for this condition, which has lead several cases to duplication as multiple different attributes can be contained in the same column
I am just trying to make sense of this currently, but believe I have used the incorrect join because where an individual has a different attribute from this result it returns an additional record.
My question is which Join should I be using, or should in this instance I be looking at writing a sub query within the where condition
You might want to use an LEFT/RIGHT or OUTER JOIN. These JOINs have a smaller result. Or you might use DISTINCT - this forces the result to not return duplicates.
You can use distinct with specified names of the columns. Maybe by using that you won't get the duplicate columns.
eg. select distinct ed.id, ed.name, ed.dob, ea.address, ed.Emailid from Employeedetails ed join Employeeaddress ea on ed.id = ea.id
So I solved this myself by using a Sub-query.
The nature of the the requirement meant that it was difficult for me to produce a list which eliminated the duplicates, because i was looking in a joined table for results which may or may not appear.
So i used a sub-query in the where clause to look for the the instances where what i was trying to exclude which was producing the false positives did appear and use the use those results to eliminate those primary keys from the original table that way using a Not In Primary Key.
Probably not the most efficient but it does work within a couple of seconds
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Besides multiple self joins on a table.
What technological benefit do table and column aliases provide?
From my research column and table aliases only help readability (if you exclude the self join scenario)
My example of multiple self join
SELECT TOP 1 s2.y, s3.a
FROM x AS s1
INNER JOIN x AS s2 ON s1.y = s2.y
INNER JOIN x as S3 ON s2.z = S3.z
The reason why the question, I am working with a system that has its own Sql wrapper generating SQL Code. I have had some issues with how the alias system is setup. Since the system generates all SQL code itself it wouldn't matter to the system to generate fully qualified names vs aliases.
You have correctly identified self-joins as one place where table aliases are strictly required.
Additionally, table and field aliases make it easier to work with RDBMS systems in scenarios where you generate SQL dynamically. Rather than having to parse the schema to identify possible collisions, you could generate unique aliases for your tables and fields to force a specific interpretation of the data model. Aliases are not strictly required in this case, but they make your code easier to write and to understand.
I have had some issues with how the alias system is setup. Since the system generates all SQL code itself it wouldn't matter to the system to generate fully qualified names vs aliases.
That is correct, as long as your system does not need to generate self-joins.
Finally, table aliases help with typing in cases when humans interact with RDBMS manually through query debuggers and other analysis tools. Again, the aliases are not required here, but they are very helpful.
SQL Aliases
SQL aliases are used to give a database table, or a column in a table, a temporary name.
Basically aliases are created to make column names more readable.
Source: http://www.w3schools.com/sql/sql_alias.asp
So they don't serve as a "technological benefit", but what they do is that you write a query, join 6 tables together (each table has a name like [ohmygodwhoeverdesignedmeshouldhavewrittenanovel] which you call with an alias as t1). Finishing your query, it runs fine, you feel good for what you have achieved, and you can easily tell what table holds the info you are looking for
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
There are two tables with a common field id. What I want to do is select all attributes for a specific id, and I'm wondering which way is more efficient.
Using INNER JOIN, and then a single SELECT * operation is done.
Select from the smaller table first, if the id exist, then select from the larger table.
In most databases, you want to do the join:
select *
from bigtable b join
smalltable s
on b.id = s.id
where b.id = #id;
SQL engines have an optimizer to determine the best execution plan for a query. As mentioned in the comment, having an index woiuld often speed this up.
By selecting from one table and then the other, you are forcing a particular execution plan.
In general, you should trust the SQL engine to produce the best execution plan. In some cases, it may be better to do one and then the other, but generally that is not true.
This will vary based on each circumstance. You can't make a generic statement saying one will always be better .
To compare you can look at execution plans, or simply run both and compare based on execution time.
Ex: if it's rare to find data in the second table, then over time it might be better to run the single query etc
I suggest you take the 2nd way.
It is a good practice to keep some main/primary info in a index table, then put extra / detail info on another big table.
To divide info into two part (main/primary | extra / detail), because most of the time, we only the the first part info, it can save the cost of large query, large data transfer, the net bandwidth.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Some of these might make little sense, but:
Sql code interpreted or compiled (and to what)?
What are joins translated into - I mean into some loops or what?
Is algorithm complexity analysis applicable to a query, for example is it possible to write really bad select - exponential in time by number of rows selected? And if so how to analyze queries?
Well ... quite general questions, so some very general answers
1) Sql code interpreted or compiled (and to what)?
SQL code is compiled in to execution plans.
2) What are joins translated into - I mean into some loops or what?
Depends on the join and the tables you're joining (as far as i know). SQL Server has some join primitives (hash join, nested loop join), depending on the objects involved in your sql code the query optimizer tries to choose the best option.
3) Not reallyIs algorithm complexity analysis applicable to a query, for example is it possible to write really bad select - exponential in time by number of rows selected? And if so how to analyze queries?
Not really sure, what you mean by that. But there are cases where you can do really bad things, for example using
SELECT TOP 1 col FROM Table ORDER BY col DESC
on a table without an index on col to find the lagest value for col instead of
SELECT MAX(col) FROM Table
You should get your hands on some/all of the books from the SQL Server internals series. They are really excellent an cover many things in great detail.
You'd get a lot of these answers by reading one of Itzik Ben-Gan's books. He covers these topics you mention in some detail.
http://tsql.solidq.com/books/index.htm