<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Database on Data Trenches</title><link>https://data-trenches.leandrof.space/tags/database/</link><description>Recent content in Database 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/database/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><item><title>SQL Count - What the count() function acually counts?</title><link>https://data-trenches.leandrof.space/posts/sqlcount/</link><pubDate>Sun, 10 Jul 2022 11:44:01 -0600</pubDate><author>leandrojlfernandes@gmail.com (Leandro Fernandes)</author><guid>https://data-trenches.leandrof.space/posts/sqlcount/</guid><description>&lt;h1 id="sql-count--what-the-count-function-actually-counts">SQL Count — What the count() function actually counts?&lt;/h1>
&lt;p>The count() function is widely used in SQL and sometimes without fully understanding the impact that the entry parameter to the function can alter the output of your results. Most commonly, the functions can have the following as inputs parameters:&lt;/p>
&lt;ol>
&lt;li>Count(*)&lt;/li>
&lt;li>Count(1)&lt;/li>
&lt;li>Count(column name)&lt;/li>
&lt;/ol>
&lt;h3 id="test-scenario">Test Scenario&lt;/h3>
&lt;p>Let’s create a table and insert a few records to try each count variation and compare the results.&lt;/p></description></item></channel></rss>