<?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>Postgresql on DevFlow · Python Django Developer Freelance</title>
    <link>https://dev-flow.io/en/tags/postgresql/</link>
    <description>Recent content in Postgresql on DevFlow · Python Django Developer Freelance</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Wed, 13 May 2026 00:00:00 +0200</lastBuildDate>
    <atom:link href="https://dev-flow.io/en/tags/postgresql/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Materialized views vs Django cache for slow queries</title>
      <link>https://dev-flow.io/en/posts/django-materialized-views-cache/</link>
      <pubDate>Wed, 13 May 2026 00:00:00 +0200</pubDate>
      <guid>https://dev-flow.io/en/posts/django-materialized-views-cache/</guid>
      <description>PostgreSQL materialized views pre-compute slow joins in Django. Here is why cache alone is not enough and how to combine both approaches in production.</description>
    </item>
    <item>
      <title>Django select_for_update(): row-level locking for concurrent transactions</title>
      <link>https://dev-flow.io/en/posts/django-select-for-update/</link>
      <pubDate>Wed, 06 May 2026 00:00:00 +0200</pubDate>
      <guid>https://dev-flow.io/en/posts/django-select-for-update/</guid>
      <description>Django select_for_update() acquires a FOR UPDATE lock at read time. Parameters nowait, skip_locked, of, no_key: concrete use cases and pitfalls.</description>
    </item>
  </channel>
</rss>
