<?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: Location of WHERE in merge via proc sql in SAS Programming</title>
    <link>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893473#M352975</link>
    <description>Yes,  libref TERADATA point to TERADATA database . IS there other propose solution due to this fact?</description>
    <pubDate>Sun, 10 Sep 2023 06:54:42 GMT</pubDate>
    <dc:creator>Ronein</dc:creator>
    <dc:date>2023-09-10T06:54:42Z</dc:date>
    <item>
      <title>Location of WHERE in merge via proc sql</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893435#M352947</link>
      <description>&lt;P&gt;Hello&lt;/P&gt;
&lt;P&gt;I run 2 versions of query and the difference is the location of WHERE clauses.&lt;/P&gt;
&lt;P&gt;In way1&amp;nbsp; the where clauses are at the end of the query.&lt;/P&gt;
&lt;P&gt;In way2&amp;nbsp; the where clauses are in the place of define the data set&amp;nbsp;&lt;/P&gt;
&lt;P&gt;My question-&lt;/P&gt;
&lt;P&gt;I was surprised that&amp;nbsp; way1 is working very quickly and way2 very slowly .&lt;/P&gt;
&lt;P&gt;I even stopped the run of way2 before it finish because it took so long time.&lt;/P&gt;
&lt;P&gt;Why Way2&amp;nbsp; is running so slowly?&lt;/P&gt;
&lt;P&gt;By theory, is Way1 better way to write the query than Way2?&lt;/P&gt;
&lt;P&gt;Apologize that&amp;nbsp; I cannot add data but it is more theoretical question.&lt;/P&gt;
&lt;P&gt;Maybe the reason is working with tables located in teradata???&lt;/P&gt;
&lt;P&gt;Is efficiency of Way1 and Way2&amp;nbsp; &amp;nbsp;is depending on the location of the source tables ?(SAS or other like TeraData)&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;/***Way1------very quick query******/
/***Way1------very quick query******/
/***Way1------very quick query******/
proc sql;
create table Way1 as
SELECT *
FROM  TeraData.t1 
INNER JOIN TeraData.t2
ON t2.Team_IP=t1.Team_IP

INNER JOIN TeraData.t3  
ON t3.Branch_Cust_IP=t1.Branch_Cust_IP

LEFT  JOIN TeraData.t4 
ON t3.Agreement_Account_Id= t4.Agreement_Account_Id

LEFT  JOIN TeraData.t5
ON t5.Agreement_Account_Id=t3.Agreement_Account_Id

LEFT  JOIN TeraData.t6
ON t6.Agreement_Account_Id=t3.Agreement_Account_Id

INNER JOIN TeraData.t7 
ON t3.Agreement_Account_Id=t7.Agreement_Account_Id

Left join  (Select * from TeraData.t8 where Agreement_Summary_Date='31DEC2022'd) 
ON t3.Agreement_Account_Id=t8.Agreement_Account_Id

where t7.Agreement_Summary_Date='31DEC2022'd
      AND t3.Agreement_Category_Code  IN  (3)   
      AND t3.Loan_Type_Code  IN  (10,20)
;
quit;


/***Way2------very slow query******/
/***Way2------very slow query******/
/***Way2------very slow query******/
proc sql;
create table Way1 as
SELECT *
FROM  TeraData.t1 
INNER JOIN TeraData.t2
ON t2.Team_IP=t1.Team_IP

INNER JOIN TeraData.t3 (Where=(Agreement_Category_Code  IN  (3)  AND Loan_Type_Code  IN  (10,20))) 
ON t3.Branch_Cust_IP=t1.Branch_Cust_IP

LEFT  JOIN TeraData.t4 
ON t3.Agreement_Account_Id= t4.Agreement_Account_Id

LEFT  JOIN TeraData.t5
ON t5.Agreement_Account_Id=t3.Agreement_Account_Id

LEFT  JOIN TeraData.t6
ON t6.Agreement_Account_Id=t3.Agreement_Account_Id

INNER JOIN TeraData.t7 (Where=(Agreement_Summary_Date='31DEC2022'd))
ON t3.Agreement_Account_Id=t7.Agreement_Account_Id

Left join  (Select * from TeraData.t8 where Agreement_Summary_Date='31DEC2022'd) 
ON t3.Agreement_Account_Id=t8.Agreement_Account_Id
;
quit;
&lt;/CODE&gt;&lt;/PRE&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 09 Sep 2023 12:45:50 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893435#M352947</guid>
      <dc:creator>Ronein</dc:creator>
      <dc:date>2023-09-09T12:45:50Z</dc:date>
    </item>
    <item>
      <title>Re: Location of WHERE in merge via proc sql</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893443#M352950</link>
      <description>&lt;P&gt;Is the libref TERADATA point to something in a TERADATA database?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I suspect that the use of the WHERE= dataset option confused PROC SQL Into thinking that it could not push all of the query into the remote database.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If you really want to get better control over the performance then you can use explicit passthru into teradata. (Note you will have to use Teradata syntax for things like date literals).&lt;/P&gt;
&lt;PRE&gt;&lt;CODE class=" language-sas"&gt;proc sql;
connect using teradata;
create table Way1 as
  SELECT * from connection to teradata
(select * 
  FROM  Schema.t1 
  INNER JOIN Schema.t2
  ON t2.Team_IP=t1.Team_IP

  INNER JOIN Schema.t3  
  ON t3.Branch_Cust_IP=t1.Branch_Cust_IP

  LEFT  JOIN Schema.t4 
  ON t3.Agreement_Account_Id= t4.Agreement_Account_Id

  LEFT  JOIN Schema.t5
  ON t5.Agreement_Account_Id=t3.Agreement_Account_Id

  LEFT  JOIN Schema.t6
  ON t6.Agreement_Account_Id=t3.Agreement_Account_Id

  INNER JOIN Schema.t7 
  ON t3.Agreement_Account_Id=t7.Agreement_Account_Id

  Left join  (Select * from Schema.t8 where Agreement_Summary_Date= date'2022-12-31') t8
  ON t3.Agreement_Account_Id=t8.Agreement_Account_Id

  where t7.Agreement_Summary_Date= date'2022-12-31'
        AND t3.Agreement_Category_Code  IN  (3)   
        AND t3.Loan_Type_Code  IN  (10,20)
)
;
quit;&lt;/CODE&gt;&lt;/PRE&gt;</description>
      <pubDate>Sat, 09 Sep 2023 16:08:06 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893443#M352950</guid>
      <dc:creator>Tom</dc:creator>
      <dc:date>2023-09-09T16:08:06Z</dc:date>
    </item>
    <item>
      <title>Re: Location of WHERE in merge via proc sql</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893473#M352975</link>
      <description>Yes,  libref TERADATA point to TERADATA database . IS there other propose solution due to this fact?</description>
      <pubDate>Sun, 10 Sep 2023 06:54:42 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893473#M352975</guid>
      <dc:creator>Ronein</dc:creator>
      <dc:date>2023-09-10T06:54:42Z</dc:date>
    </item>
    <item>
      <title>Re: Location of WHERE in merge via proc sql</title>
      <link>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893475#M352977</link>
      <description>&lt;P&gt;According to this SAS white paper:&lt;/P&gt;
&lt;P&gt;&lt;A href="http://support.sas.com/resources/papers/teradata.pdf" target="_blank" rel="noopener"&gt;http://support.sas.com/resources/papers/teradata.pdf&lt;/A&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;the use of dataset options disqualifies a query from being passed to the DB (page 14).&lt;/P&gt;
&lt;P&gt;Leave the WHERE where it is.&lt;/P&gt;</description>
      <pubDate>Sun, 10 Sep 2023 09:00:40 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Programming/Location-of-WHERE-in-merge-via-proc-sql/m-p/893475#M352977</guid>
      <dc:creator>Kurt_Bremser</dc:creator>
      <dc:date>2023-09-10T09:00:40Z</dc:date>
    </item>
  </channel>
</rss>

