<?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>Question Re: Late materialization insert processing in Technology Q&amp;A</title>
    <link>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaa-p/730815#M204249</link>
    <description>&lt;P&gt;I'd take the beer and the island trip - long time that I've been to Mallorca.&lt;/P&gt;&lt;P&gt;Anyhow, the late materialisation is not the critical factor here. Your system simply does not seem to have enough memory to hold the result set and the target table storage structures (MAIN, DELTA, DELTA2, MAIN2) for the time the INSERT statement is running.&lt;/P&gt;&lt;P&gt;The whole result set has to be materialized and then written into the target table delta. In between, delta merges will happen, that copy large amounts of data between DELTA and MAIN as well as MAIN, DELTA and MAIN2 (assuming there will be multiple delta merges).&lt;/P&gt;&lt;P&gt;I wouldn't give too much on the cardinality estimation in the explain plan - out of memory errors occur when memory for actual data is requested and in this case this data seems to be too much.&lt;/P&gt;&lt;P&gt;How large is the system memory, by the way? And have you checked with PlanViz how much memory/how many records actually end up in the target table?&lt;/P&gt;&lt;P&gt;One option for a workaround could be to partition the target table so that the delta merges can occur in smaller chunks.&lt;/P&gt;</description>
    <pubDate>Tue, 04 Dec 2018 02:28:16 GMT</pubDate>
    <dc:creator>lbreddemann</dc:creator>
    <dc:date>2018-12-04T02:28:16Z</dc:date>
    <item>
      <title>Late materialization insert processing</title>
      <link>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaq-p/730813</link>
      <description>&lt;P&gt;Hi gurus, I´ve a performance problem inserting a large result-set (180M), coming from a select clause, into Hana DB. Although the sql clause runs ok, when i add the insert clause, i get an OOM. I have studing the case carefully, and looking for a late materialization issue. The plan of the select with and without insert are the next:&lt;/P&gt;
  &lt;P&gt;&lt;IMG class="migrated-image" src="https://community.sap.com/legacyfs/online/storage/attachments/storage/7/attachments/245717-insert-select.png" /&gt;&lt;/P&gt;
  &lt;P&gt;&lt;IMG class="migrated-image" src="https://community.sap.com/legacyfs/online/storage/attachments/storage/7/attachments/245718-select.png" /&gt;&lt;/P&gt;
  &lt;P&gt;In the insert, we dont have a Late Materialization processing. Since it´s an error new for me and is difficult to find appropiate documentation, i can´t figure out if thats the normal behaviour, or not. Should has the insert COLUMN SEARCH operator the LATE MATERIALIZATION processing?&lt;/P&gt;
  &lt;P&gt; &lt;SPAN class="mention-scrubbed"&gt;lars.breddemann&lt;/SPAN&gt; any inside advicing would be really appreciated! Sorry for the inconvenience, if you came to Mallorca you have some beers for sure &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
  &lt;P&gt;Kind regards!&lt;/P&gt;</description>
      <pubDate>Mon, 03 Dec 2018 13:56:30 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaq-p/730813</guid>
      <dc:creator>former_member234712</dc:creator>
      <dc:date>2018-12-03T13:56:30Z</dc:date>
    </item>
    <item>
      <title>Re: Late materialization insert processing</title>
      <link>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaa-p/730814#M204248</link>
      <description>&lt;P&gt;Forget to say that the late materialization threshold for both select and insert are much less than the expected number of records, so shouldn´t be that the problem.&lt;/P&gt;</description>
      <pubDate>Mon, 03 Dec 2018 15:32:35 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaa-p/730814#M204248</guid>
      <dc:creator>former_member234712</dc:creator>
      <dc:date>2018-12-03T15:32:35Z</dc:date>
    </item>
    <item>
      <title>Re: Late materialization insert processing</title>
      <link>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaa-p/730815#M204249</link>
      <description>&lt;P&gt;I'd take the beer and the island trip - long time that I've been to Mallorca.&lt;/P&gt;&lt;P&gt;Anyhow, the late materialisation is not the critical factor here. Your system simply does not seem to have enough memory to hold the result set and the target table storage structures (MAIN, DELTA, DELTA2, MAIN2) for the time the INSERT statement is running.&lt;/P&gt;&lt;P&gt;The whole result set has to be materialized and then written into the target table delta. In between, delta merges will happen, that copy large amounts of data between DELTA and MAIN as well as MAIN, DELTA and MAIN2 (assuming there will be multiple delta merges).&lt;/P&gt;&lt;P&gt;I wouldn't give too much on the cardinality estimation in the explain plan - out of memory errors occur when memory for actual data is requested and in this case this data seems to be too much.&lt;/P&gt;&lt;P&gt;How large is the system memory, by the way? And have you checked with PlanViz how much memory/how many records actually end up in the target table?&lt;/P&gt;&lt;P&gt;One option for a workaround could be to partition the target table so that the delta merges can occur in smaller chunks.&lt;/P&gt;</description>
      <pubDate>Tue, 04 Dec 2018 02:28:16 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaa-p/730815#M204249</guid>
      <dc:creator>lbreddemann</dc:creator>
      <dc:date>2018-12-04T02:28:16Z</dc:date>
    </item>
    <item>
      <title>Re: Late materialization insert processing</title>
      <link>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaa-p/730816#M204250</link>
      <description>&lt;P&gt;For sure you have your beers! &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt; Thanks for your help Lars, i´ve been working tunning the SQL in 2 main points:&lt;/P&gt;&lt;P&gt;- Partitioning destination table like you recomend--&amp;gt; get us major improvements in inserting time and memory consumption&lt;/P&gt;&lt;P&gt;- Rewriting logic from calculation view to plain sql--&amp;gt; major improvements in memory consumption.&lt;/P&gt;&lt;P&gt;At the end, the memory consumption becomes stable and in reazonable limits.&lt;/P&gt;&lt;P&gt;Thanks again Lars!!!!!!&lt;/P&gt;</description>
      <pubDate>Wed, 05 Dec 2018 14:25:29 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/late-materialization-insert-processing/qaa-p/730816#M204250</guid>
      <dc:creator>former_member234712</dc:creator>
      <dc:date>2018-12-05T14:25:29Z</dc:date>
    </item>
  </channel>
</rss>

