In the last post about Writing Postgres Extensions, we covered the basics of extending PostgresSQL with extension. Now it’s time for the fun part – developing our own type.
Postgres has a ton of features and offers a wide range of data types, functions, operators, and aggregates. But sometimes it’s just not enough for your use case. Luckily, it’s easy to extend Postgres’ functionality through extension. So why not write your own?
One of Postgres’ most powerful features is its extensibility. Although Postgres offers a large number of data types, functions, operators, and aggregates, sometimes you may still want more. Postgres itself already comes with a large amount of additional extensions. Even more can be installed through the PostgreSQL Extension Network and if that is not enough for you, you can also write your own.
However, there isn’t a standard tool for managing Postgres dependencies in applications. To avoid falling into the dependency hell and to enable lean extension development, we developed pgbundle - the Postgres extension management tool.
This article will show you how to create a network with 5 virtual machines which have public IP addresses and can be accessed via Internet. Virtual machines will run on Gentoo.
I hate writing tests. There’s only one thing I hate more: not having tests. So I like it when writing and running tests for anything is easy.
In part 1 of Rex in practice series, we got started with describing our infrastructure as code. All of those automation bits are kept in git repositories. They are nothing but code after all. Since they are code, we want them covered by tests.
Facebook does it, Google does it, Twitter does it. There are many companies that create databases and lists for you to be able to re-engage and re-target your mobile app users. But why not do it yourself and be independent of any 3rd party to tell you who your users are. Today, as a first article of a series, we want to show you the theoretical basics of user databases and why you should run them yourself.
As part of our export functions for adjust.com, we generate CSV reports for our clients, which are typically used to create pivot tables in Office. Sometimes those reports can be 100’s of megabytes in size and Office will not be able to open them. And even those files that can be opened often take minutes to load.
Being asked one too many times to “quickly” check one of those reports I came across a very helpful little tool to transform CSVs into SQL without all the hustle of creating complex table structures.
“Unrolling” line charts are everywhere - where the lines gradually enter from origin, point by point. This is the world’s favourite way of animating a line chart, particularly as it makes a ton of sense when graphing a time series. d3 tends to transition line charts really weirdly, though. So what is d3 actually doing when creating transitions on line charts, and how can we make them prettier?
Here at adjust we use Redis as a fast in memory key-value data store. Today I want to show you how we are clustering Redis.