https://andrepoupard.com/ Recent content on Andre Poupard Hugo -- gohugo.io en-us Tue, 10 Oct 2023 20:26:14 -0300 https://andrepoupard.com/post/index-black-magic/ Tue, 10 Oct 2023 20:26:14 -0300 https://andrepoupard.com/post/index-black-magic/ A coworker of mine found himself in a spot where index used by his database query was working as intended BUT the performance was still too slow. What are you supposed to do in this situation? The easiest thing to do is to play around with the query/indices and try out some query rewriting tricks. If you’re using PostgreSQL or MySQL this would be done by placing EXPLAIN before your query. https://andrepoupard.com/post/merge-statement/ Fri, 08 Sep 2023 21:43:09 -0400 https://andrepoupard.com/post/merge-statement/ If I asked you to come up with all the different kinds of CRUD query statements you could think of, what statements would come to mind? INSERT, SELECT, UPDATE, DELETE are easy to come by. What about the less common MERGE statement? It’s used when you’d like to update one table from another “data source”. A data source could be almost anything, from VALUES statements, to subqueries, to other tables. https://andrepoupard.com/post/immutable-index/ Mon, 07 Aug 2023 15:43:50 -0400 https://andrepoupard.com/post/immutable-index/ If you’ve been using PostgreSQL long enough, you know that B+tree indices are the way to go in most cases. But that’s not the case for some immutable tables. What index should you use for immutable tables (no updates/deletes) where the column values are stored in ascending order physically and logically? BRIN Indices. A good candidate for this type of index would be a created_at column, each new row has an increasing value similar to its physical layout on disc. https://andrepoupard.com/post/stateful-triggers/ Mon, 31 Jul 2023 00:00:25 -0400 https://andrepoupard.com/post/stateful-triggers/ When working with database triggers, you might find yourself in a situation where you want to add extra state to your trigger that goes beyond just the fields on the row. Perhaps you’re looking to add some additional application level state. For instance, let’s say you wanted a trigger to store the user_id of a user that performed an action within your system but user_id is not a part of the record nor can it be looked up from another table based on that field. https://andrepoupard.com/post/postgresql-btree-indices/ Tue, 25 Jul 2023 18:58:16 -0400 https://andrepoupard.com/post/postgresql-btree-indices/ Often when you index tables, you’ll start to notice that indices tend to cover the same field and over again. You start by adding this index: CREATE INDEX user_username_indx ON user(username) Weeks go by and you feel like adding this: CREATE INDEX user_username_created_at_indx ON user(username, created_at) You can do that; however, the original index already “covers” this case! You’re adding more indices that have to be maintained for no reason. https://andrepoupard.com/post/faster-than-primary-key/ Mon, 17 Jul 2023 17:54:44 -0400 https://andrepoupard.com/post/faster-than-primary-key/ In PostgreSQL, what’s the fastest way to search for a single record? If you said primary key or some field with an index, there’s a much faster way. Rows on disc Each row is stored in a fixed sized page, and each page contains slots for each row. The primary key index stores the page and offset id of the row that you’re looking for. You can access the tuple by that page and offset id instead of traversing the index first. https://andrepoupard.com/post/fly-without-branches/ Wed, 12 Jul 2023 19:07:56 -0400 https://andrepoupard.com/post/fly-without-branches/ Your boss comes running up to you and says: “We have a stream with billions of integers, I want you to filter out the ones between 5 and 25!” “That sounds easy enough. No probl–” “One slight problem, you can’t sort the numbers in the stream and it has to be as fast as possible.” You start coding away and come up with the below pseudo python code like a champ: https://andrepoupard.com/post/go-memory-leaks/ Tue, 11 Jul 2023 23:36:19 -0400 https://andrepoupard.com/post/go-memory-leaks/ “There’s been something wrong with our Go server for the past 2 years…”, my colleague says. My mind shuts off in anticipation of what’s to come. “We’ve had several devs investigate this issue from our backend lead to various members from other backend teams but still with no luck.” What could this be? “It’s a memory leak and it causes constant crashes. Our users get kicked off of the websockets each time and they can’t view any content for some time. https://andrepoupard.com/about/ Mon, 01 Jan 0001 00:00:00 +0000 https://andrepoupard.com/about/