<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>PostgreSQL on Data Trenches</title><link>https://data-trenches.leandrof.space/tags/postgresql/</link><description>Recent content in PostgreSQL on Data Trenches</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><managingEditor>leandrojlfernandes@gmail.com (Leandro Fernandes)</managingEditor><webMaster>leandrojlfernandes@gmail.com (Leandro Fernandes)</webMaster><lastBuildDate>Mon, 10 Jun 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://data-trenches.leandrof.space/tags/postgresql/index.xml" rel="self" type="application/rss+xml"/><item><title>PostgreSQL 17 Beta: B-Tree just got promoted to Index CEO</title><link>https://data-trenches.leandrof.space/posts/postgresql-17-btree/</link><pubDate>Mon, 10 Jun 2024 00:00:00 +0000</pubDate><author>leandrojlfernandes@gmail.com (Leandro Fernandes)</author><guid>https://data-trenches.leandrof.space/posts/postgresql-17-btree/</guid><description>&lt;p>The release of &lt;a href="https://www.postgresql.org/about/news/postgresql-17-beta-1-released-2865/">PostgreSQL 17 beta&lt;/a> brought a bunch of new interesting features. Improvements to the vacuum execution time, memory consumption, faster ANALYZE, etc.., but the one that most databases and developers will appreciate that also caught my eye right off the bat, are the improvements to the B-Tree Index when using the IN or ANY clauses. I&amp;rsquo;ve read improvements ranging from 10% to 30% without any change to your database or table structure so I wanted to test it out for one of my production use cases.&lt;/p></description></item><item><title>PostgreSQL: A deep dive of Prepared Statements</title><link>https://data-trenches.leandrof.space/posts/postgresql-prepared-statements/</link><pubDate>Mon, 27 May 2024 00:00:00 +0000</pubDate><author>leandrojlfernandes@gmail.com (Leandro Fernandes)</author><guid>https://data-trenches.leandrof.space/posts/postgresql-prepared-statements/</guid><description>&lt;p>In a PostgreSQL database, preparing a statement involves parsing, analyzing and rewriting that specific statement. The result is compiled and stored in memory (which is usually called as statement caching). When a previous prepared statement is executed, PostgreSQL can skip the parsing, analyzing and rewriting steps and use the precompiled version instead. This can significantly improve database performance, especially for queries that are executed frequently or have complex plans. The more you execute a query, the bigger the probability for you to see significant improvements.&lt;/p></description></item></channel></rss>