<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Stressing the performance query againt one table on a warehouse in Data Warehouse</title>
    <link>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4244992#M1854</link>
    <description>&lt;P&gt;Hi &lt;a href="javascript:void(0)" data-lia-user-mentions="" data-lia-user-uid="719515" data-lia-user-login="pmscorca" class="lia-mention lia-mention-user"&gt;pmscorca&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;There are several SQL queries that you can use for stresstesting. You can think of:&lt;BR /&gt;&lt;STRONG&gt;&lt;BR /&gt;Reporting Queries with Complex Aggregations&lt;/STRONG&gt;&lt;BR /&gt;SELECT&lt;BR /&gt;CustomerID,&lt;BR /&gt;SUM(TotalAmount) AS TotalSpent,&lt;BR /&gt;COUNT(OrderID) AS NumberOfOrders,&lt;BR /&gt;AVG(TotalAmount) AS AverageOrderValue&lt;BR /&gt;FROM Orders&lt;BR /&gt;WHERE OrderDate BETWEEN '2023-01-01' AND '2023-12-31'&lt;BR /&gt;GROUP BY CustomerID&lt;BR /&gt;ORDER BY TotalSpent DESC;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Recursive Common Table Expression (CTE)&lt;BR /&gt;&lt;/STRONG&gt;WITH RecursiveOrgChart AS (&lt;BR /&gt;SELECT EmployeeID, ManagerID, 1 AS Level&lt;BR /&gt;FROM Employees&lt;BR /&gt;WHERE ManagerID IS NULL&lt;BR /&gt;&lt;BR /&gt;UNION ALL&lt;BR /&gt;&lt;BR /&gt;SELECT e.EmployeeID, e.ManagerID, roc.Level + 1&lt;BR /&gt;FROM Employees e&lt;BR /&gt;INNER JOIN RecursiveOrgChart roc ON e.ManagerID = roc.EmployeeID&lt;BR /&gt;)&lt;BR /&gt;SELECT *&lt;BR /&gt;FROM RecursiveOrgChart&lt;BR /&gt;ORDER BY Level;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Window Functions over Large Data Sets&lt;BR /&gt;&lt;/STRONG&gt;SELECT&lt;BR /&gt;EmployeeID,&lt;BR /&gt;Salary,&lt;BR /&gt;RANK() OVER (PARTITION BY DepartmentID ORDER BY Salary DESC) AS SalaryRank&lt;BR /&gt;FROM Employees&lt;BR /&gt;WHERE HireDate BETWEEN '2000-01-01' AND '2023-01-01';&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Lag and Lead Functions&lt;/STRONG&gt;&lt;BR /&gt;SELECT&lt;BR /&gt;StockID,&lt;BR /&gt;PriceDate,&lt;BR /&gt;ClosePrice,&lt;BR /&gt;LAG(ClosePrice, 1) OVER (PARTITION BY StockID ORDER BY PriceDate) AS PreviousClosePrice,&lt;BR /&gt;LEAD(ClosePrice, 1) OVER (PARTITION BY StockID ORDER BY PriceDate) AS NextClosePrice,&lt;BR /&gt;(ClosePrice - LAG(ClosePrice, 1) OVER (PARTITION BY StockID ORDER BY PriceDate)) AS PriceChange,&lt;BR /&gt;(LEAD(ClosePrice, 1) OVER (PARTITION BY StockID ORDER BY PriceDate) - ClosePrice) AS PredictedChange&lt;BR /&gt;FROM StockPrices&lt;BR /&gt;WHERE PriceDate BETWEEN '2023-01-01' AND '2023-12-31'&lt;BR /&gt;ORDER BY StockID, PriceDate;&lt;/P&gt;</description>
    <pubDate>Wed, 16 Oct 2024 14:34:20 GMT</pubDate>
    <dc:creator>FabianSchut</dc:creator>
    <dc:date>2024-10-16T14:34:20Z</dc:date>
    <item>
      <title>Stressing the performance query againt one table on a warehouse</title>
      <link>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4244950#M1853</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;on a warehouse I've one table with 33 columns, having some datetime columns, some varchar columns, some bit columns and some integer columns.&lt;/P&gt;&lt;P&gt;I need to stress the performance query on this single table: I've already tried to use some DATEDIFF functions, registering good query times, but I'd like to proof some queries more time intensive, considering that a warehouse is based on delta format.&lt;/P&gt;&lt;P&gt;Any suggests to me, please? Many thanks&lt;/P&gt;</description>
      <pubDate>Wed, 16 Oct 2024 13:57:00 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4244950#M1853</guid>
      <dc:creator>pmscorca</dc:creator>
      <dc:date>2024-10-16T13:57:00Z</dc:date>
    </item>
    <item>
      <title>Re: Stressing the performance query againt one table on a warehouse</title>
      <link>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4244992#M1854</link>
      <description>&lt;P&gt;Hi &lt;a href="javascript:void(0)" data-lia-user-mentions="" data-lia-user-uid="719515" data-lia-user-login="pmscorca" class="lia-mention lia-mention-user"&gt;pmscorca&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;There are several SQL queries that you can use for stresstesting. You can think of:&lt;BR /&gt;&lt;STRONG&gt;&lt;BR /&gt;Reporting Queries with Complex Aggregations&lt;/STRONG&gt;&lt;BR /&gt;SELECT&lt;BR /&gt;CustomerID,&lt;BR /&gt;SUM(TotalAmount) AS TotalSpent,&lt;BR /&gt;COUNT(OrderID) AS NumberOfOrders,&lt;BR /&gt;AVG(TotalAmount) AS AverageOrderValue&lt;BR /&gt;FROM Orders&lt;BR /&gt;WHERE OrderDate BETWEEN '2023-01-01' AND '2023-12-31'&lt;BR /&gt;GROUP BY CustomerID&lt;BR /&gt;ORDER BY TotalSpent DESC;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Recursive Common Table Expression (CTE)&lt;BR /&gt;&lt;/STRONG&gt;WITH RecursiveOrgChart AS (&lt;BR /&gt;SELECT EmployeeID, ManagerID, 1 AS Level&lt;BR /&gt;FROM Employees&lt;BR /&gt;WHERE ManagerID IS NULL&lt;BR /&gt;&lt;BR /&gt;UNION ALL&lt;BR /&gt;&lt;BR /&gt;SELECT e.EmployeeID, e.ManagerID, roc.Level + 1&lt;BR /&gt;FROM Employees e&lt;BR /&gt;INNER JOIN RecursiveOrgChart roc ON e.ManagerID = roc.EmployeeID&lt;BR /&gt;)&lt;BR /&gt;SELECT *&lt;BR /&gt;FROM RecursiveOrgChart&lt;BR /&gt;ORDER BY Level;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Window Functions over Large Data Sets&lt;BR /&gt;&lt;/STRONG&gt;SELECT&lt;BR /&gt;EmployeeID,&lt;BR /&gt;Salary,&lt;BR /&gt;RANK() OVER (PARTITION BY DepartmentID ORDER BY Salary DESC) AS SalaryRank&lt;BR /&gt;FROM Employees&lt;BR /&gt;WHERE HireDate BETWEEN '2000-01-01' AND '2023-01-01';&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Lag and Lead Functions&lt;/STRONG&gt;&lt;BR /&gt;SELECT&lt;BR /&gt;StockID,&lt;BR /&gt;PriceDate,&lt;BR /&gt;ClosePrice,&lt;BR /&gt;LAG(ClosePrice, 1) OVER (PARTITION BY StockID ORDER BY PriceDate) AS PreviousClosePrice,&lt;BR /&gt;LEAD(ClosePrice, 1) OVER (PARTITION BY StockID ORDER BY PriceDate) AS NextClosePrice,&lt;BR /&gt;(ClosePrice - LAG(ClosePrice, 1) OVER (PARTITION BY StockID ORDER BY PriceDate)) AS PriceChange,&lt;BR /&gt;(LEAD(ClosePrice, 1) OVER (PARTITION BY StockID ORDER BY PriceDate) - ClosePrice) AS PredictedChange&lt;BR /&gt;FROM StockPrices&lt;BR /&gt;WHERE PriceDate BETWEEN '2023-01-01' AND '2023-12-31'&lt;BR /&gt;ORDER BY StockID, PriceDate;&lt;/P&gt;</description>
      <pubDate>Wed, 16 Oct 2024 14:34:20 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4244992#M1854</guid>
      <dc:creator>FabianSchut</dc:creator>
      <dc:date>2024-10-16T14:34:20Z</dc:date>
    </item>
    <item>
      <title>Re: Stressing the performance query againt one table on a warehouse</title>
      <link>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4245113#M1855</link>
      <description>&lt;P&gt;Hi, thanks for your reply.&lt;/P&gt;&lt;P&gt;Saying again that I need to query only on a single table without joining with other tables,&lt;/P&gt;&lt;P&gt;I've noticed that sometimes when a query is executed for the first time, in a new SQL query window or in an idle existing SQL query windows, the query time is more high than the next runs: is it a normal behaviour? Why?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 16 Oct 2024 15:45:41 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4245113#M1855</guid>
      <dc:creator>pmscorca</dc:creator>
      <dc:date>2024-10-16T15:45:41Z</dc:date>
    </item>
    <item>
      <title>Re: Stressing the performance query againt one table on a warehouse</title>
      <link>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4245206#M1856</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="javascript:void(0)" data-lia-user-mentions="" data-lia-user-uid="719515" data-lia-user-login="pmscorca" class="lia-mention lia-mention-user"&gt;pmscorca&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;All the query examples that I gave can be executed with a single table. The&amp;nbsp;&lt;STRONG&gt;Recursive Common Table Expression (CTE) example that I gave uses a recursive cte on the same table, it uses the same table twice.&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;About your first time execution, that is normal behaviour, as can be seen in this documentation:&amp;nbsp;&lt;A href="https://learn.microsoft.com/en-us/fabric/data-warehouse/guidelines-warehouse-performance#cold-run-cold-cache-performance" target="_blank"&gt;https://learn.microsoft.com/en-us/fabric/data-warehouse/guidelines-warehouse-performance#cold-run-cold-cache-performance&lt;/A&gt;&amp;nbsp;&lt;BR /&gt;"&lt;SPAN&gt;The first 1-3 executions of a query perform noticeably slower than subsequent executions.&lt;/SPAN&gt;"&lt;/STRONG&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 16 Oct 2024 17:08:14 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/Data-Warehouse/Stressing-the-performance-query-againt-one-table-on-a-warehouse/m-p/4245206#M1856</guid>
      <dc:creator>FabianSchut</dc:creator>
      <dc:date>2024-10-16T17:08:14Z</dc:date>
    </item>
  </channel>
</rss>

