<?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 SAS/DI Snowflake metadata (in-)efficiency in Developers</title>
    <link>https://communities.sas.com/t5/Developers/SAS-DI-Snowflake-metadata-in-efficiency/m-p/973865#M6644</link>
    <description>&lt;P&gt;Since replacing Cloudera with Snowflake a few years ago, we constantly have to battle with the Snowflake ODBC connection. Getting data to and from Snowflake is fine - but when we have to access the metadata the process slows to a crawl. It &lt;EM&gt;appears&lt;/EM&gt; to be doing a scan of all metadata, possibly because of the underscore in the schema names of *****_dev, *****_test and so on. Yeah, bit silly, but there you go.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I've written my bespoke ingestion code within DI to compensate for that: using the &lt;EM&gt;exist&lt;/EM&gt; function takes thirty seconds or so, whereas using the&amp;nbsp;&lt;EM&gt;open&lt;/EM&gt; function and checking for success/fail is virtually instantenous. While we investigate the processes required to change the schema names, there's another issue with pass-through SQL joins, related to automatic deletion of the target table.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If I set up a user-written transformation, I can tell it not to delete the target table &lt;EM&gt;(Inputs/Outputs * Automatically generate delete code for outputs&lt;/EM&gt;).&amp;nbsp;But if I do an SQL join, it generates&amp;nbsp;&lt;EM&gt;proc datasets/delete&lt;/EM&gt; and there doesn't seem to be any way to get around it. For a SAS output dataset, it doesn't matter, but if it's a table accessed via a Snowflake libname, again we're hit with the 30-second delay while the whole schema metadata is scanned to find the table. If there are half a dozen joins in a job, that's quite a hit.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is there any way to turn this behaviour off? I've looked everywhere in all the options and I can't find it.&lt;/P&gt;</description>
    <pubDate>Mon, 01 Sep 2025 20:45:37 GMT</pubDate>
    <dc:creator>LaurieF</dc:creator>
    <dc:date>2025-09-01T20:45:37Z</dc:date>
    <item>
      <title>SAS/DI Snowflake metadata (in-)efficiency</title>
      <link>https://communities.sas.com/t5/Developers/SAS-DI-Snowflake-metadata-in-efficiency/m-p/973865#M6644</link>
      <description>&lt;P&gt;Since replacing Cloudera with Snowflake a few years ago, we constantly have to battle with the Snowflake ODBC connection. Getting data to and from Snowflake is fine - but when we have to access the metadata the process slows to a crawl. It &lt;EM&gt;appears&lt;/EM&gt; to be doing a scan of all metadata, possibly because of the underscore in the schema names of *****_dev, *****_test and so on. Yeah, bit silly, but there you go.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I've written my bespoke ingestion code within DI to compensate for that: using the &lt;EM&gt;exist&lt;/EM&gt; function takes thirty seconds or so, whereas using the&amp;nbsp;&lt;EM&gt;open&lt;/EM&gt; function and checking for success/fail is virtually instantenous. While we investigate the processes required to change the schema names, there's another issue with pass-through SQL joins, related to automatic deletion of the target table.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If I set up a user-written transformation, I can tell it not to delete the target table &lt;EM&gt;(Inputs/Outputs * Automatically generate delete code for outputs&lt;/EM&gt;).&amp;nbsp;But if I do an SQL join, it generates&amp;nbsp;&lt;EM&gt;proc datasets/delete&lt;/EM&gt; and there doesn't seem to be any way to get around it. For a SAS output dataset, it doesn't matter, but if it's a table accessed via a Snowflake libname, again we're hit with the 30-second delay while the whole schema metadata is scanned to find the table. If there are half a dozen joins in a job, that's quite a hit.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is there any way to turn this behaviour off? I've looked everywhere in all the options and I can't find it.&lt;/P&gt;</description>
      <pubDate>Mon, 01 Sep 2025 20:45:37 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Developers/SAS-DI-Snowflake-metadata-in-efficiency/m-p/973865#M6644</guid>
      <dc:creator>LaurieF</dc:creator>
      <dc:date>2025-09-01T20:45:37Z</dc:date>
    </item>
  </channel>
</rss>

