To some extent, it gets worse with larger numbers. Try this:

DECLARE @tmp1 FLOAT = 10e27;
SELECT CONVERT(decimal(38,2),ROUND(@tmp1, 2)*100),
       CONVERT(decimal(38,2),ROUND(@tmp1, 2))*100,
 ...

Yes, a strange result. Try this:

DECLARE @tmp1 FLOAT = 0.289;
SELECT CONVERT(decimal(38,36),ROUND(@tmp1, 2)*100),
       CONVERT(decimal(38,36),ROUND(@tmp1, 2))*100

-- drop all user defined stored procedures 
Declare @procName varchar(500) 
Declare cur Cursor 
For Select [name] From sys.objects where type = 'p' 

Open cur 

Fetch Next...

Select PP_SUPP.PP_SUP_NO SupplierCode,
       PP_SAD.PP_SAD_REF SupplierAddressCode,
       GD_CST.GD_CST_FNAME SupplierFullName,
       GD_CST.GD_CST_ADD1 SupplierAddressLine1,
...

Looks ok to me.

If you want non-integer averages you can do this by adding 0.0 to the count:

with postcount (postid,postcount) as 
(
select postid,count(relatedpostid)+0.0 as postcount 
 ...

<li style="list-style-type: none;">

• yesterday about 13-17hours was possible run this query only with MAXDOP 1,2,3,4

<li style="list-style-type: none;">

• yesterday after 18 and more was possible run only with...

The plan looks the same, the estimates are the same, and it even continues to suggest that I create that same index that I just created. (Yes, it's really...

What happens if you create the suggested index? Do both queries use it?

There is no difference in the execution plan. Just the number of rows estimated.

There is quite a lot wrong with your SQL, I've just pasted in something that will work.

drop table [dbo].[Table_1]
GO
drop table [dbo].[Table_2]
GO
CREATE TABLE [dbo].[Table_1](
[KEYU] [int] IDENTITY(1,1) NOT NULL,
[DATA1]...

There is no difference in the number of reads, so maybe (as the optimiser is a bit of a black box), in that case, the optimiser doesn't change the order...

If you run the queries with

SET STATISTICS IO, TIME ON

Is there any difference in the results? If so can you paste them in here?

On thing I've noticed from a very quick look as that the left joins seem to be very similar.

I would look at combining the LEFT JOINS into one query on...

I don't think it should make any difference, as the optimiser will/should work out the best order to execute the joins. So both queries should have the same execution plan...

I don't understand what you want? What sort of ideas are you looking for?