<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" >

  <channel>
    <title><![CDATA[Статьи]]></title>
    <link>https://habr.com/ru/users/nullstack/publications/articles/</link>
    <description><![CDATA[Хабр: статьи пользователя nullstack]]></description>
    <language>ru</language>
    <managingEditor>editor@habr.com</managingEditor>
    <generator>habr.com</generator>
    <pubDate>Tue, 28 Jul 2026 07:51:59 GMT</pubDate>
    
    
      <image>
        <link>https://habr.com/ru/</link>
        <url>https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png</url>
        <title>Хабр</title>
      </image>
    

    
      
        
    
    <item>
      <title><![CDATA[Когда успешная миграция сломалась, а партиционирование превратилось в cross-cluster move]]></title>
      <guid isPermaLink="true">https://habr.com/ru/companies/rwb/articles/1000530/</guid>
      <link>https://habr.com/ru/companies/rwb/articles/1000530/?utm_campaign=1000530&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<img src="https://habrastorage.org/getpro/habr/upload_files/445/7bd/638/4457bd6383b6381422255e99b070ad1c.jpg" /><p>Привет! На связи вновь команда Геосервисов. Как вы помните, в прошлой статье я делился нашим опытом партиционирования и теми выводами, к которым мы пришли. Но на этом история не закончилась. Что же было дальше?  </p><p><strong>Партиционирование завершилось успешно</strong>. VACUUM сократился с 6+ часов до ~20 минут. Запросы ускорились. Мы думали, что всё позади. Через неделю после swap проверили реплику — и обнаружили, что она пуста.</p> <a href="https://habr.com/ru/articles/1000530/?utm_campaign=1000530&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать далее</a>]]></description>
      
      <pubDate>Sat, 28 Feb 2026 09:51:00 GMT</pubDate>
      <dc:creator><![CDATA[NullStack (RWB)]]></dc:creator>
      <category><![CDATA[Блог компании RWB]]></category><category><![CDATA[Go]]></category><category><![CDATA[PostgreSQL]]></category>
      <category><![CDATA[golang]]></category><category><![CDATA[postgresql]]></category><category><![CDATA[postgresql performance]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Партиционирование PostgreSQL: опыт команды Геосервисов]]></title>
      <guid isPermaLink="true">https://habr.com/ru/companies/rwb/articles/1000514/</guid>
      <link>https://habr.com/ru/companies/rwb/articles/1000514/?utm_campaign=1000514&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<img src="https://habrastorage.org/getpro/habr/upload_files/aec/249/1b2/aec2491b24c3b2e414d9272f44e111d0.jpg" /><p>Всем привет! Поводом для написания этой статьи послужила ситуация, с которой мы в команде Геосервисов столкнулись.</p><p>Когда наша база данных нормализованных OSM-данных достигла размеров в 600+ ГБ, VACUUM стал занимать 6+ часов. Мы начали приближаться к пределу хранилища (600 GB из 1 TB), а производительность запросов деградировала. Стало очевидным — партиционирование неизбежно.</p><p><strong>В этой статье</strong>: как мы готовили миграцию, какие грабли собрали, и почему для управления долгоживущим процессом недостаточно стандартного мониторинга.</p> <a href="https://habr.com/ru/articles/1000514/?utm_campaign=1000514&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать далее</a>]]></description>
      
      <pubDate>Thu, 26 Feb 2026 14:49:48 GMT</pubDate>
      <dc:creator><![CDATA[NullStack (RWB)]]></dc:creator>
      <category><![CDATA[Блог компании RWB]]></category><category><![CDATA[PostgreSQL]]></category><category><![CDATA[Go]]></category>
      <category><![CDATA[postgresql]]></category><category><![CDATA[partitioning]]></category><category><![CDATA[osm]]></category>
    </item>
  

  

  

	
  

  

  

      

      

      

    
  </channel>
</rss>
