<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Migrations on Murat Useinov</title>
    <link>https://useinov.com/tags/migrations/</link>
    <description>Recent content in Migrations on Murat Useinov</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 17 Mar 2022 22:40:00 +0300</lastBuildDate>
    <atom:link href="https://useinov.com/tags/migrations/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Backfill in batches, not in one UPDATE</title>
      <link>https://useinov.com/posts/2022/batched-backfill/</link>
      <pubDate>Thu, 17 Mar 2022 22:40:00 +0300</pubDate>
      <guid>https://useinov.com/posts/2022/batched-backfill/</guid>
      <description>&lt;p&gt;Sixty million rows in &lt;code&gt;orders&lt;/code&gt;, a new nullable column &lt;code&gt;total_cents&lt;/code&gt; from expand-and-contract, and a Friday afternoon. The question is how to fill it.&lt;/p&gt;
&lt;p&gt;The naive answer is one statement. &lt;code&gt;UPDATE orders SET total_cents = ROUND(total * 100)&lt;/code&gt;. On a test database it works. On production it holds row locks on the whole table for the whole run, writes one giant chunk of WAL, and the replica falls minutes behind. On MySQL the binlog gets the same present. One project I worked on learned this on that Friday. Since then I backfill only in batches.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
