I’m excited to be speaking at Citus Con 2023 on April 18-19 on reducing your PostgreSQL costs on Azure managed Postgres.
In my talk, I’ll be sharing tips and tricks that can help you save money without sacrificing performance. Join me at the upcoming conference to learn more about how you can optimize your Azure PostgreSQL deployment and reduce your costs.
Whether you’re just getting started with Azure Postgres or you’re a seasoned pro, my talk will provide valuable insights and tips for optimizing your use of the platform. I’m looking forward to sharing my knowledge with the PostgreSQL community and learning from other experts in the field. See you at Citus Con 2023!
“Sharing your knowledge and learnings about Postgres—or Postgres extensions (like the Citus database extension)—is a useful way to give back to the community. Your talk can help other teams & projects learn from your successes (and mistakes) with Postgres.”
Thank Claire, for your inspiring words. They have really motivated me and given me the encouragement I needed for giving this talk. 🙌
Whenever you are dealing with pattern matching in PostgreSQL, it is often required to write queries to match string patterns. The conventional wisdom to do pattern match was using the LIKE operator, which is not very effective for many reasons. PostgreSQL now offers more advanced pattern matching options such as SIMILAR TO expressions, POSIX regularexpressions, and ANYoperator. In this article, we’ll compare the LIKE operator with these other advanced pattern matching features.
In this 4th post, I’ll show you how to use Value window functions – that can be used to calculate various “value” type aggregations such as Lag, Lead, First_Value and Last_Value within each group of rows referred here as “window” or “partition”.
This is 3rd post in my series featuring Window Function in PostgreSQL. In this post, I’ll explain how to use Ranking window functions – that we can use to calculate various aggregations such as Row Number, Rank, and Dense Rank within each window or partition.
Here we go, after weeks for procrastination finally the 2nd post in my series featuring Window Function in PostgreSQL. In this post, I’ll explain how to use Aggregate window functions – that we can use to calculate various aggregations such as average, counts, minimum / maximum values, and sum within each window or partition.
Window functions are a powerful tool that helps to leverage the power of PostgreSQL for Data Analysis. In this blog series, I will explain what window functions are, why you should use them, types of window functions and finally will introduce you to some basic window functions in PostgreSQL. In the next few post, I’ll go through more advanced window functions and demo some scenarios. So let’s get going.
Ok, so you’ve stored hierarchical data in a relational database, and written recursive CTEs to query the data and find relationships. Now the application team wants to query hierarchical levels and print the complete ancestry tree. Time to deep dive into some advance CTE constructs.
This is the second post of the series about the Recursive SQL for querying hierarchical data started in the previous post . If you haven’t read it already, I recommend reading it to understand the key concepts:
What is a hierarchical data?
How to store hierarchical data in a relational database?
And how to query hierarchical data using:
Common Table Expressions (CTE)
In this post, we’ll discuss the advanced scenarios like displaying hierarchical levels and printing the “ancestry tree”. Let’s dive in…
Recently, I was working on an application that required reading hierarchically structured data. And I thought it might be useful to document multiple ways to store and query such hierarchical data (ex. Org. chart, File-system layout, or Set of tasks in a project) in a database. So, let’s jump right in.
Definitions first – what is hierarchical data?
Hierarchical data is a specific kind of data, characterized by a hierarchical relationship between the data sets.
Think about data sets having multiple levels: something above, something below, and a few at the same level. A typical example of such hierarchical model is an organizational chart like the one below.
Most modern-day relational database systems use SQL MERGE (also called UPSERT) statements to INSERT new records or UPDATE existing records if a matching row already exists. UPSERT is a combination of Insert and Update, driven by a “PRIMARY KEY” on the table.