<?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: Proc sql join performance with Index in SAS Programming</title>
    <link>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349652#M81149</link>
    <description>Before jumping to any conclusions you need more information. &lt;BR /&gt;Add&lt;BR /&gt;Options msglevel =i fullstimer; &lt;BR /&gt;This will give more information about basic processing and systems constraints. &lt;BR /&gt;&lt;BR /&gt;Proc SQL _method; &lt;BR /&gt;Will give you the SQL plan.</description>
    <pubDate>Thu, 13 Apr 2017 03:16:51 GMT</pubDate>
    <dc:creator>LinusH</dc:creator>
    <dc:date>2017-04-13T03:16:51Z</dc:date>
    <item>
      <title>Proc sql join performance with Index</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349574#M81100</link>
      <description>&lt;P&gt;I have two datasets - Big (100 million rows) and small (200,000 rows). The Big dataset is indexed by a unique key.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I have two queries in sequence doing a left join from the small to the big dataset which looks like this:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;&lt;CODE class=" language-sas"&gt;proc sql;
select *
from a left join b
on a.key=b.key;
quit;&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;The first time the query runs for 20-30 minutes, but the second time takes only 2-3 minutes. Why does this happen? Is it possible to do something to reduce the runtime for the first query as well?&lt;/P&gt;</description>
      <pubDate>Wed, 12 Apr 2017 19:39:47 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349574#M81100</guid>
      <dc:creator>set_all__</dc:creator>
      <dc:date>2017-04-12T19:39:47Z</dc:date>
    </item>
    <item>
      <title>Re: Proc sql join performance with Index</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349600#M81117</link>
      <description>&lt;P&gt;The big dataset does need that much time to run.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Below is some information might help.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="http://analytics.ncsu.edu/sesug/2011/BB08.Lafler.pdf" target="_blank"&gt;http://analytics.ncsu.edu/sesug/2011/BB08.Lafler.pdf&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;There are a number of common reasons for slow-running queries and updates:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;
&lt;P&gt;Slow network communication.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;Inadequate memory in the server computer, or not enough memory available .&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;Lack of useful statistics&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;Lack of useful indexes.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;Lack of useful indexed views.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;Lack of useful data striping.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;Lack of useful partitioning.&lt;/P&gt;
&lt;/LI&gt;
&lt;/UL&gt;</description>
      <pubDate>Wed, 12 Apr 2017 20:29:00 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349600#M81117</guid>
      <dc:creator>Bal23</dc:creator>
      <dc:date>2017-04-12T20:29:00Z</dc:date>
    </item>
    <item>
      <title>Re: Proc sql join performance with Index</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349606#M81122</link>
      <description>&lt;P&gt;The most likely reason for the faster second join is that the data has been cached by your server hardware / OS. You could prove this by swapping the queries around, if possible, to see a similar effect.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;A faster solution would be to use a SAS format built from the small table to do the data lookup. That way you avoid joining entirely.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 12 Apr 2017 20:33:09 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349606#M81122</guid>
      <dc:creator>SASKiwi</dc:creator>
      <dc:date>2017-04-12T20:33:09Z</dc:date>
    </item>
    <item>
      <title>Re: Proc sql join performance with Index</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349607#M81123</link>
      <description>&lt;P&gt;Your "small" dataset was probably found in the filesystem cache the second time. A normal behaviour that speeds up access to frequently used files by keeping them in memory.&lt;/P&gt;</description>
      <pubDate>Wed, 12 Apr 2017 20:35:26 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349607#M81123</guid>
      <dc:creator>jklaverstijn</dc:creator>
      <dc:date>2017-04-12T20:35:26Z</dc:date>
    </item>
    <item>
      <title>Re: Proc sql join performance with Index</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349652#M81149</link>
      <description>Before jumping to any conclusions you need more information. &lt;BR /&gt;Add&lt;BR /&gt;Options msglevel =i fullstimer; &lt;BR /&gt;This will give more information about basic processing and systems constraints. &lt;BR /&gt;&lt;BR /&gt;Proc SQL _method; &lt;BR /&gt;Will give you the SQL plan.</description>
      <pubDate>Thu, 13 Apr 2017 03:16:51 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Proc-sql-join-performance-with-Index/m-p/349652#M81149</guid>
      <dc:creator>LinusH</dc:creator>
      <dc:date>2017-04-13T03:16:51Z</dc:date>
    </item>
  </channel>
</rss>

