network profile
| bio | website | sqlsoft.co.uk |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 2 years, 4 months |
| seen | Apr 26 at 10:43 | |
| stats | profile views | 6 |
|
Mar 5 |
awarded | Yearling |
|
Mar 5 |
awarded | Popular Question |
|
Feb 10 |
answered | Performance differences between executing via Linked Server vs. SSMS |
|
Feb 5 |
awarded | Student |
|
Feb 5 |
awarded | Scholar |
|
Feb 5 |
awarded | Commentator |
|
Dec 28 |
awarded | Teacher |
|
May 31 |
comment |
Optimising join on large table Thanks - that's a mighty big table. |
|
May 31 |
comment |
Optimising join on large table @Quick Joe Smith - the more you toy with database optimization, the more you learn, it's a process of eroding your misconceptions - I know it was for me. :) |
|
May 31 |
comment |
Optimising join on large table @Quick Joe Smith - thanks for the sp_spaceused. 75GB of index and 18GB of data - is ix_hugetable not the only index on the table? |
|
May 31 |
comment |
Optimising join on large table But there's more to it than this. If #smalltable had a large number of rows then a merge join might be appropriate. If, as it's name suggests, it has a small number of rows then a loop join could be the right choice. Imagine #smalltable had one or two rows, and matched vs. a handful of rows from the other table - it would be hard to justify a merge join here. |
|
May 31 |
comment |
Optimising join on large table Could you include the result of sp_spaceused 'dbo.hugetable', please? |
|
May 31 |
answered | Optimising join on large table |
|
May 20 |
comment |
How to improve sql server 2008 table scan speed? Please attach the output of DBCC SHOWCONTIG(yourtablename) WITH TABLERESULTS |
|
May 17 |
comment |
Error Msg 823, Level 24, State 2, Line 1 Have you tried the suggested DBCC CHECKDB? Also, verify the backup with RESTORE VERIFYONLY - msdn.microsoft.com/en-us/library/ms189587.aspx |
|
Jan 28 |
awarded | Supporter |
|
Jul 8 |
accepted | SQL Server - Temporary vs. Physical Tables |
|
Jul 4 |
comment |
SQL Server - Temporary vs. Physical Tables Looks useful - thanks SPE109, I'll check into this and make recommendations to our DBA as appropriate. |
|
Jul 4 |
comment |
SQL Server - Temporary vs. Physical Tables I'm all for not following this path if it's not justifiable - thanks for the information Ben - I'll investigate and make suggestions to our DBA as appropriate. |
|
Jul 4 |
comment |
SQL Server - Temporary vs. Physical Tables I totally agree with the above Remus - and thanks for an excellent response. The problem is that we are causing a supposed performance hit on a third parties applications (with several databases on a server on which we have a database of our own - we need to perform queries vs. their data). I still think you're right, mind - I/O wise I would expect the new approach to perform considerably worse than previously - contention wise, from tempdbs point of view things'll be better - from ours, somewhat worse. |
