It seems logical to me that a hash match is a more efficient engine than a
sort on an index. I have several views that make up a final view. (Written
by my superior). He wants to use this view, but it takes forever. I am
using his view. It takes forever. I believe that if a single view that
creates the same recordset instead of referencing a view within a view shoul
d
be faster. My problem is showing this to be the case as the view on view
itself shows the subtree cost to be 2.7 and the single view shows a cost of
3.65 but there are no sorts involved.
What is confusing is that if I replace the view on view query with the
single query, the cost of the view remains 2.7 despite the fact that it is
the same as the one for 3.65. The time involved in this query is more than
can be afforded. Can anyone tell me whether a hash is faster than a sort o
n
a large table?
--
Regards,
Jamie"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
> (Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
> should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
> of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
> than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
> on
> a large table?
If a view is written correctly there should be no performance penalty
whether you query against the view or bypass it.
As to the hash match or sort, the question is too vague to answer. It
depends on the query, the schema and the statistics.
David|||Have you looked at covering indexes or possibly an indexed view?
Are the join columns indexed?
The view on view should have no penalty, it is more of an administrative
hassle than anything else.
As far as the Hashing goes, that depends. Table structures, index
structures, statistical data and so forth.
Rick Sawtell
MCT, MCSD, MCDBA
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
(Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
on
> a large table?
> --
> Regards,
> Jamie
Showing posts with label views. Show all posts
Showing posts with label views. Show all posts
Wednesday, March 21, 2012
Hash Match Faster Than Index Sort?
It seems logical to me that a hash match is a more efficient engine than a
sort on an index. I have several views that make up a final view. (Written
by my superior). He wants to use this view, but it takes forever. I am
using his view. It takes forever. I believe that if a single view that
creates the same recordset instead of referencing a view within a view should
be faster. My problem is showing this to be the case as the view on view
itself shows the subtree cost to be 2.7 and the single view shows a cost of
3.65 but there are no sorts involved.
What is confusing is that if I replace the view on view query with the
single query, the cost of the view remains 2.7 despite the fact that it is
the same as the one for 3.65. The time involved in this query is more than
can be afforded. Can anyone tell me whether a hash is faster than a sort on
a large table?
Regards,
Jamie
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
> (Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
> should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
> of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
> than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
> on
> a large table?
If a view is written correctly there should be no performance penalty
whether you query against the view or bypass it.
As to the hash match or sort, the question is too vague to answer. It
depends on the query, the schema and the statistics.
David
|||Have you looked at covering indexes or possibly an indexed view?
Are the join columns indexed?
The view on view should have no penalty, it is more of an administrative
hassle than anything else.
As far as the Hashing goes, that depends. Table structures, index
structures, statistical data and so forth.
Rick Sawtell
MCT, MCSD, MCDBA
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
(Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
on
> a large table?
> --
> Regards,
> Jamie
sql
sort on an index. I have several views that make up a final view. (Written
by my superior). He wants to use this view, but it takes forever. I am
using his view. It takes forever. I believe that if a single view that
creates the same recordset instead of referencing a view within a view should
be faster. My problem is showing this to be the case as the view on view
itself shows the subtree cost to be 2.7 and the single view shows a cost of
3.65 but there are no sorts involved.
What is confusing is that if I replace the view on view query with the
single query, the cost of the view remains 2.7 despite the fact that it is
the same as the one for 3.65. The time involved in this query is more than
can be afforded. Can anyone tell me whether a hash is faster than a sort on
a large table?
Regards,
Jamie
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
> (Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
> should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
> of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
> than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
> on
> a large table?
If a view is written correctly there should be no performance penalty
whether you query against the view or bypass it.
As to the hash match or sort, the question is too vague to answer. It
depends on the query, the schema and the statistics.
David
|||Have you looked at covering indexes or possibly an indexed view?
Are the join columns indexed?
The view on view should have no penalty, it is more of an administrative
hassle than anything else.
As far as the Hashing goes, that depends. Table structures, index
structures, statistical data and so forth.
Rick Sawtell
MCT, MCSD, MCDBA
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
(Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
on
> a large table?
> --
> Regards,
> Jamie
sql
Hash Match Faster Than Index Sort?
It seems logical to me that a hash match is a more efficient engine than a
sort on an index. I have several views that make up a final view. (Written
by my superior). He wants to use this view, but it takes forever. I am
using his view. It takes forever. I believe that if a single view that
creates the same recordset instead of referencing a view within a view should
be faster. My problem is showing this to be the case as the view on view
itself shows the subtree cost to be 2.7 and the single view shows a cost of
3.65 but there are no sorts involved.
What is confusing is that if I replace the view on view query with the
single query, the cost of the view remains 2.7 despite the fact that it is
the same as the one for 3.65. The time involved in this query is more than
can be afforded. Can anyone tell me whether a hash is faster than a sort on
a large table?
--
Regards,
Jamie"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
> (Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
> should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
> of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
> than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
> on
> a large table?
If a view is written correctly there should be no performance penalty
whether you query against the view or bypass it.
As to the hash match or sort, the question is too vague to answer. It
depends on the query, the schema and the statistics.
David|||Have you looked at covering indexes or possibly an indexed view?
Are the join columns indexed?
The view on view should have no penalty, it is more of an administrative
hassle than anything else.
As far as the Hashing goes, that depends. Table structures, index
structures, statistical data and so forth.
Rick Sawtell
MCT, MCSD, MCDBA
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
(Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
on
> a large table?
> --
> Regards,
> Jamie
sort on an index. I have several views that make up a final view. (Written
by my superior). He wants to use this view, but it takes forever. I am
using his view. It takes forever. I believe that if a single view that
creates the same recordset instead of referencing a view within a view should
be faster. My problem is showing this to be the case as the view on view
itself shows the subtree cost to be 2.7 and the single view shows a cost of
3.65 but there are no sorts involved.
What is confusing is that if I replace the view on view query with the
single query, the cost of the view remains 2.7 despite the fact that it is
the same as the one for 3.65. The time involved in this query is more than
can be afforded. Can anyone tell me whether a hash is faster than a sort on
a large table?
--
Regards,
Jamie"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
> (Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
> should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
> of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
> than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
> on
> a large table?
If a view is written correctly there should be no performance penalty
whether you query against the view or bypass it.
As to the hash match or sort, the question is too vague to answer. It
depends on the query, the schema and the statistics.
David|||Have you looked at covering indexes or possibly an indexed view?
Are the join columns indexed?
The view on view should have no penalty, it is more of an administrative
hassle than anything else.
As far as the Hashing goes, that depends. Table structures, index
structures, statistical data and so forth.
Rick Sawtell
MCT, MCSD, MCDBA
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:CC3DC120-DF5A-4F22-959B-F4D92E87C3FE@.microsoft.com...
> It seems logical to me that a hash match is a more efficient engine than a
> sort on an index. I have several views that make up a final view.
(Written
> by my superior). He wants to use this view, but it takes forever. I am
> using his view. It takes forever. I believe that if a single view that
> creates the same recordset instead of referencing a view within a view
should
> be faster. My problem is showing this to be the case as the view on view
> itself shows the subtree cost to be 2.7 and the single view shows a cost
of
> 3.65 but there are no sorts involved.
> What is confusing is that if I replace the view on view query with the
> single query, the cost of the view remains 2.7 despite the fact that it is
> the same as the one for 3.65. The time involved in this query is more
than
> can be afforded. Can anyone tell me whether a hash is faster than a sort
on
> a large table?
> --
> Regards,
> Jamie
Friday, February 24, 2012
Handling error level 16
Hello there
I have some store procedure that run on many views by cursor. One of the
views is failed on error level 16. And therefore the batch is being
terminated.
Is there a way not to terminate the procedure and continue?Roy Goldhammer (roy@.hotmail.com) writes:
>Date: Thu, 20 Apr 2006 10:04:29 +0200
Hey, I am in that time zone, and my watch is only 9:30!
> I have some store procedure that run on many views by cursor. One of the
> views is failed on error level 16. And therefore the batch is being
> terminated.
> Is there a way not to terminate the procedure and continue?
If you are on SQL 2000, you are basically out of luck. Some errors in SQL
Server terminates the batch, and there is no easy way to handle it.
If you are on SQL 2005, you can use the new TRY-CATCH construct.
If your aim is to run sp_refreshview on these views, search on Google
for FMTONLY + sp_refreshview. I saw a tip on that recently, but I don't
recall exactly in which newsgroup.
For more information about error handling in SQL Server, see
http://www.sommarskog.se/error-handling-I.html
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Whell Erland.
I'm using sql server 2000.
The main error that comes is error converting.
and it is level 16 and therefore the statement is being terminated
is there something i can do to solve it?
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns97AB61A39F364Yazorman@.127.0.0.1...
> Roy Goldhammer (roy@.hotmail.com) writes:
> Hey, I am in that time zone, and my watch is only 9:30!
>
> If you are on SQL 2000, you are basically out of luck. Some errors in SQL
> Server terminates the batch, and there is no easy way to handle it.
> If you are on SQL 2005, you can use the new TRY-CATCH construct.
> If your aim is to run sp_refreshview on these views, search on Google
> for FMTONLY + sp_refreshview. I saw a tip on that recently, but I don't
> recall exactly in which newsgroup.
> For more information about error handling in SQL Server, see
> http://www.sommarskog.se/error-handling-I.html
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx|||Roy
What does the script do? Do you convert dates?
"Roy Goldhammer" <roy@.hotmail.com> wrote in message
news:OI5duAFZGHA.4248@.TK2MSFTNGP05.phx.gbl...
> Whell Erland.
> I'm using sql server 2000.
> The main error that comes is error converting.
> and it is level 16 and therefore the statement is being terminated
> is there something i can do to solve it?
> "Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
> news:Xns97AB61A39F364Yazorman@.127.0.0.1...
>|||Roy Goldhammer (roy@.hotmail.com) writes:
> I'm using sql server 2000.
> The main error that comes is error converting.
> and it is level 16 and therefore the statement is being terminated
> is there something i can do to solve it?
The level does not matter. Error handling in SQL Server is inconsistent.
In my previous post I suggested a search, and gave a link to that article.
Rather than asking again, without telling what you are doing, why not try
the references you got?
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
I have some store procedure that run on many views by cursor. One of the
views is failed on error level 16. And therefore the batch is being
terminated.
Is there a way not to terminate the procedure and continue?Roy Goldhammer (roy@.hotmail.com) writes:
>Date: Thu, 20 Apr 2006 10:04:29 +0200
Hey, I am in that time zone, and my watch is only 9:30!
> I have some store procedure that run on many views by cursor. One of the
> views is failed on error level 16. And therefore the batch is being
> terminated.
> Is there a way not to terminate the procedure and continue?
If you are on SQL 2000, you are basically out of luck. Some errors in SQL
Server terminates the batch, and there is no easy way to handle it.
If you are on SQL 2005, you can use the new TRY-CATCH construct.
If your aim is to run sp_refreshview on these views, search on Google
for FMTONLY + sp_refreshview. I saw a tip on that recently, but I don't
recall exactly in which newsgroup.
For more information about error handling in SQL Server, see
http://www.sommarskog.se/error-handling-I.html
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Whell Erland.
I'm using sql server 2000.
The main error that comes is error converting.
and it is level 16 and therefore the statement is being terminated
is there something i can do to solve it?
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns97AB61A39F364Yazorman@.127.0.0.1...
> Roy Goldhammer (roy@.hotmail.com) writes:
> Hey, I am in that time zone, and my watch is only 9:30!
>
> If you are on SQL 2000, you are basically out of luck. Some errors in SQL
> Server terminates the batch, and there is no easy way to handle it.
> If you are on SQL 2005, you can use the new TRY-CATCH construct.
> If your aim is to run sp_refreshview on these views, search on Google
> for FMTONLY + sp_refreshview. I saw a tip on that recently, but I don't
> recall exactly in which newsgroup.
> For more information about error handling in SQL Server, see
> http://www.sommarskog.se/error-handling-I.html
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx|||Roy
What does the script do? Do you convert dates?
"Roy Goldhammer" <roy@.hotmail.com> wrote in message
news:OI5duAFZGHA.4248@.TK2MSFTNGP05.phx.gbl...
> Whell Erland.
> I'm using sql server 2000.
> The main error that comes is error converting.
> and it is level 16 and therefore the statement is being terminated
> is there something i can do to solve it?
> "Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
> news:Xns97AB61A39F364Yazorman@.127.0.0.1...
>|||Roy Goldhammer (roy@.hotmail.com) writes:
> I'm using sql server 2000.
> The main error that comes is error converting.
> and it is level 16 and therefore the statement is being terminated
> is there something i can do to solve it?
The level does not matter. Error handling in SQL Server is inconsistent.
In my previous post I suggested a search, and gave a link to that article.
Rather than asking again, without telling what you are doing, why not try
the references you got?
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
Subscribe to:
Posts (Atom)