Daniel Westermann

Converting columns from one data type to another in PostgreSQL

Usually you should use the data type that best fits the representation of your data in a relational database. But how many times did you see applications that store dates or numbers as text or dates as integers? This is(…)

Telling the PostgreSQL optimizer more about your functions

When you reference/call functions in PostgreSQL the optimizer does not really know much about the cost nor the amount of rows that a function returns. This is not really surprising as it is hard to predict what the functions is(…)

Modifying pg_hba.conf from inside PostgreSQL

During one of the sessions from the last Swiss PGDay there was a question which could not be answered during the talk: Is it possible to modify pg_hba.conf from inside PostgreSQL without(…)

PostgreSQL on the beach, PGIBZ, recap

So, finally, PostgreSQL on the beach is over. During discussions it was mentioned that some companies had issues to justify sending people to a conference to Ibiza. It was not really clear if they wanted to avoid the impression of(…)

PostgreSQL partitioning (8): Sub-partitioning

We are slowly coming to the end of this little series about partitioning in PostgreSQL. In the last post we had a look at indexing and constraints and today we will have a look at sub partitioning. Sub partitioning means(…)

PostgreSQL partitioning (7): Indexing and constraints

Yesterday we talked about attaching and detaching of partitions. Today we will look at indexing and constraints when it comes to partitioned tables. If you missed the last posts, again, here they are: PostgreSQL partitioning (1):(…)

PostgreSQL partitioning (6): Attaching and detaching partitions

Having talked about partitioning strategies and partition pruning this time we will have a look on how you can attach and detach partitions to and from an existing partitioned table. If you missed the last posts about partitioning in PostgreSQL(…)

PostgreSQL partitioning (5): Partition pruning

This is the next post in the PostgreSQL partitioning series. If you missed the previous ones here they are: PostgreSQL partitioning (1): Preparing the data set PostgreSQL partitioning (2): Range partitioning(…)

PostgreSQL partitioning (4): Hash partitioning

The last partitioning strategy we will look at is: hash partitioning. If you missed the first posts in this series here they are: PostgreSQL partitioning (1): Preparing the data set PostgreSQL partitioning(…)

PostgreSQL partitioning (3): List partitioning

In the last posts of this series we prepared the data set and had a look at range partitioning. In this post we look at another partitioning strategy: List partitioning. Instead of(…)