sebiwi

Counting the florbs: BRIN indexes, rollup tables, and a 90-second query

sebiwi — Mon, 22 Jun 2026 09:00:00 +0200

TL;DR

I needed to count the florbs. All of them, across the whole system, over any time window you care to name. The florbs lived in Postgres, so I tried using a BRIN index, which was great for small windows and useless for large ones. Then I built a daily rollup table to pre-aggregate the counts, kept the BRIN around for the small stuff, and ended up with a query that went from about 90 seconds to a handful of milliseconds.

If you keep reading, I’m going to tell you what a BRIN index is, why it’s great, why it wasn’t enough, how a rollup table works, and how to use it for big counts.

The florbs

I’m not going to tell you what a florb is. It doesn’t matter (trust me). It’s better this way. It’s more fun too. Here’s everything you actually need to know.

There are about fifteen million florbs living in a Postgres database. There are more of them every second. Each florb is either still florbing, has florbed cleanly, or has failed to florb, and each one takes some amount of time to do so. They belong to different tenants. One day, someone important walked over and asked a perfectly reasonable question: across all of them, what fraction of florbs are failing right now? And last week? And over the last 90 days?

We already had a way to look at one tenant’s florbs. What we didn’t have was the global view: every florb, every tenant, an arbitrary time window, the error rate at a glance. So I went to build it.

It’s just counting, right?

First attempt: a BRIN index

The florbs live in one big ass table, and the only thing my query filters on is created_at. Count the rows in a time window, group by status, done. The naive version is fine until the table gets big, and fifteen million rows is big enough to make a plain sequential scan crawl. In other words, not something you want to run on every dashboard load.

So then I index created_at. Florbs are append-mostly, and they arrive roughly in time order. This means that the table is already physically laid out on disk in created_at order. That is the exact situation BRIN indexes were built for.

A BRIN index (Block Range INdex) is super lazy. I like that. Instead of storing one entry per row like a B-tree, it slices the table in ranges of physical blocks and stores only the minimum and maximum value of the indexed column for each range. That’s the whole idea. For a table sorted by time, each block range covers a small slice of time, so when you ask for “florbs created last Tuesday”, Postgres can skip every block range whose min and max don’t overlap Tuesday, and only look at the few that do. Other databases do this too, they just don’t call them BRIN: ClickHouse does minmax skip indexes, for example.

The result is an index that is small (kilobytes, not gigabytes), costs almost nothing to maintain on insert, and makes narrow time-window queries fast. A one-day window dropped to around 268 milliseconds. Problem solved. Right?

Where it fell apart

BRIN indexes are lossy: a block range only tells Postgres that matching rows might live in those blocks, never that they definitely do. Postgres still has to read every block in the matching ranges and re-check each row by hand. When your window is narrow and only a handful of ranges match, that recheck is cheap. When your window is wide, it’s expensive.

A 30-day window matched about 4.4 million rows, roughly 30% of the table. At that point the planner did the sensible thing and gave up on the index entirely: if you’re going to read a third of the table anyway, the bookkeeping of a lossy index is pure overhead, so it fell back to a parallel sequential scan. That scan took about 89 seconds. The 90-day window was worse.

But then I started thinking about this differently. A sequential scan reads the whole table no matter how wide your window is. One day or ninety days, same cost, because it reads everything either way. There is no index in the world that fixes this, because the problem was never finding the rows. The problem is that there are simply too many of them to count on demand. The BRIN index was a good answer to a subset of the question.

Second attempt: a rollup table

Alright, counting fifteen million florbs on every request is too slow, let’s not do that. How about counting them once ahead of time, and keep the running totals around?

That’s a rollup table. Mine pre-aggregates the florbs by day, at a grain of (tenant, day, status). A whole day’s worth of florbs for a given tenant and status collapses into a single row holding a count. A wide-window query then sums a few thousand pre-aggregated rows instead of scanning millions of raw ones.

There is one design decision here that matters more than all the others: store the raw data, never the finished answers. It is tempting to store an average_duration or a failure_rate directly. Don’t do that. If you want to combine two days, a stored average is useless, because the average of two averages is a lie unless both days had exactly the same number of florbs.

So instead of an average I store a sum_duration_ms and a duration_count, and instead of a rate I store the raw counts per status. Then any span of days reconstructs perfectly: the failure rate is SUM(failed) / SUM(total), and the average duration is SUM(sum_duration_ms) / SUM(duration_count), both computed at read time over however many days you asked for. Same numbers as the live query, every single time.

The cool side effect is that this table barely grows. Its size depends on the number of tenants, statuses, and days, not on the number of florbs. A year of history is a few hundred thousand rows, which is kinda nothing.

Reads route themselves by window width. Narrow windows (under a week) still hit the live table through the BRIN index, where they’re fast, exact, and perfectly fresh. Wide windows hit the rollup. Best of both worlds.

Keeping it fresh

The rollup is rebuilt by a small loop that runs inside the app itself: refresh once on startup, then every fifteen minutes. Since many instances of the app are running, they all coordinate through a Postgres advisory lock, so exactly one of them does the work at a time and the rest happily do nothing (execute but no-op). No cron, no extra service, no new infrastructure, fresh and frugal.

Two interesting implementation details here. First, each refresh deletes and rebuilds a trailing window of days rather than upserting, because a florb can change its verdict after the fact (it goes from still florbing to florbed or failed), which means a bucket’s count can go down, and an upsert would never notice. Second, it only recomputes the last few days, because a florb’s timestamp never changes once it is created, so older buckets are already final. That recompute is a quick, BRIN-assisted scan of recent rows. There’s one assumption here, based on my florbs behavior: the trailing window has to be at least as long as a florb can take to settle. If a florb could keep florbing for longer than the window, it would age out still counted as running, and its final verdict would never make it into the rollup. Your florbs may behave differently.

There is also a small downside: rollup answers can be up to fifteen minutes stale, and they are aligned to day boundaries at the very edges of the window. On a 90-day dashboard, it’s a rounding error. On the narrow windows where you would actually notice, you’re reading the live table anyway, so it doesn’t apply.

The data model, if you want to steal it

Here is the whole pattern, anonymized into the florb domain, ready to adapt. The base table is whatever you already have; the only assumptions are a timestamp and a status:

-- The table you already have. Append-mostly, naturally ordered by time.
CREATE TABLE florbs (
 id BIGSERIAL PRIMARY KEY,
 tenant_id INTEGER NOT NULL,
 status TEXT NOT NULL, -- 'running' | 'completed' | 'failed'
 created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
 duration_ms BIGINT -- NULL until the florb finishes
);

Step one, the BRIN index, for the narrow windows:

CREATE INDEX CONCURRENTLY idx_florbs_created_at_brin
 ON florbs
 USING BRIN (created_at)
 WITH (pages_per_range = 32);

Step two, the rollup table. Notice that it stores counts and duration components, never averages or rates:

CREATE TABLE florb_daily_stats (
 tenant_id INTEGER NOT NULL,
 day DATE NOT NULL, -- (created_at AT TIME ZONE 'UTC')::date
 status TEXT NOT NULL,
 count BIGINT NOT NULL DEFAULT 0,
 sum_duration_ms BIGINT NOT NULL DEFAULT 0,
 duration_count BIGINT NOT NULL DEFAULT 0,
 refreshed_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
 PRIMARY KEY (tenant_id, day, status)
);

CREATE INDEX idx_florb_daily_stats_day ON florb_daily_stats (day);

Step three, the refresh. Delete a trailing window and rebuild it in one transaction, behind an advisory lock so only one process runs it. Here $1 is something like today minus three days:

SELECT pg_try_advisory_xact_lock(8675309); -- losers no-op; one runner at a time.

-- $1 must be a UTC-midnight boundary, or the oldest day is deleted but only partly rebuilt.
DELETE FROM florb_daily_stats
WHERE day >= ($1 AT TIME ZONE 'UTC')::date;

INSERT INTO florb_daily_stats
 (tenant_id, day, status, count, sum_duration_ms, duration_count, refreshed_at)
SELECT tenant_id,
 (created_at AT TIME ZONE 'UTC')::date AS day,
 status,
 COUNT(*),
 COALESCE(SUM(duration_ms), 0),
 COUNT(duration_ms),
 NOW()
FROM florbs
WHERE created_at >= $1
GROUP BY tenant_id, day, status;

And finally the read, reconstructing the stats from the stored components over whatever window you want:

SELECT
 SUM(count) AS total,
 SUM(count) FILTER (WHERE status = 'completed') AS completed,
 SUM(count) FILTER (WHERE status = 'failed') AS failed,
 SUM(count) FILTER (WHERE status = 'running') AS running,
 SUM(sum_duration_ms) / NULLIF(SUM(duration_count), 0) AS avg_duration_ms
FROM florb_daily_stats
WHERE day >= $1 AND day <= $2;

That last query is the whole point. It touches a few thousand rows, reconstructs the same totals and averages the live query would have computed, and returns fast. Add a tenant_id filter and you get a per-tenant view out of the same table.

Proof: reading the query plans

Data trumps debate, so let’s look at what Postgres actually did. An EXPLAIN ANALYZE on the two paths tells the complete story.

First, the wide-window query against the live table, the one we’re trying to avoid (a narrower window than the 90-second worst case, but still wide enough to make the point):

Parallel Bitmap Heap Scan on florbs
 Index: idx_florbs_created_at_brin
 Heap Blocks: lossy=154514
 Rows Removed by Index Recheck: 26511
 Buffers: read=416403 (~3.3 GB off disk)
 rows ≈ 1.78M
Execution Time: 11014 ms

Everything painful is right there. Heap Blocks: lossy and Rows Removed by Index Recheck are the BRIN tax: Postgres visited about 154,000 blocks the index said might match, then threw away the rows that didn’t. It read about 416,000 pages, roughly 3.3 GB, and aggregated 1.78 million rows, even with parallel workers helping. Eleven seconds, and that was one of the faster runs. The grouped variant took about 13.6 seconds.

Now the same question, answered from the rollup:

Bitmap Index Scan on idx_florb_daily_stats_day
 Index Cond: day >= '2026-06-01' AND day <= '2026-06-14'
Bitmap Heap Scan on florb_daily_stats
 rows = 3031 Buffers: read=240
Execution Time: 29.875 ms

Three thousand rows instead of nearly two million. Two hundred and forty pages instead of four hundred thousand. About 30 milliseconds cold, and under 10 milliseconds once the cache is warm. That works out to roughly 370 times faster while reading around 1,750 times fewer pages.

Same numbers out, three orders of magnitude less work to get them.

Final thoughts

I did consider other options before reaching for a second table. A big covering B-tree index would have made the scan index-only, but it scales with the number of rows matched, so 90-day windows would still be measured in seconds, and it is a large index to maintain on every insert. A dedicated time-series database is the textbook tool for this kind of question, except that florbs mutate after they are created, and most time-series stores really don’t want you updating points after the fact, so it was the wrong shape for the data. The data could have been modeled differently in this scenario, but it still implied adding an extra infrastructure component, with its operational overhead. The boring relational rollup won on simplicity.

Lessons learned:

Match the index to how you query the data, and when no index can save you, stop querying the raw data and pre-aggregate it.
BRIN was the right tool for small windows and a trap for large ones, and knowing the difference is most of the job.

You still wanna know what a florb is? Why? Some mysteries are load-bearing.

You are not your code

sebiwi — Mon, 11 Nov 2019 07:19:02 +0100

You are not your code. This code looks like it's been written by an imbecil. That remark is about your code, not about you.

DST

sebiwi — Mon, 04 Nov 2019 07:19:02 +0100

DST makes my head spin and I often wonder about the reasons we're still using it. It must be hard to tell people that all of their suffering was for nothing.

ext5

sebiwi — Mon, 28 Oct 2019 07:19:02 +0100

KPI

sebiwi — Mon, 21 Oct 2019 07:19:02 +0100

Libra

sebiwi — Mon, 14 Oct 2019 07:19:02 +0100

If I wanted my financial transaction information to be used for political advertisement, I'd give it to Cambridge Analytica myself.

The Powershell diaries: part 1

sebiwi — Mon, 07 Oct 2019 07:19:02 +0100

I spent 15 minutes trying to figure out how to get my Powershell version. Turns out the syntax is harder than quitting vim.

42

sebiwi — Mon, 30 Sep 2019 07:19:02 +0100

If she'd written the Hitchhiker's guide to the Galaxy, the Answer to the Ultimate Question of Life, the Universe, and Everything would be vim.

Disagreement

sebiwi — Mon, 23 Sep 2019 07:19:02 +0100

Person 1: Truth comes from disagreement, so may I suggest..? Person 2: No. Person 1: Disagreement should be constructive. Person 2: I disagree.

Technical

sebiwi — Mon, 16 Sep 2019 07:19:02 +0100

Often, people think all of their problems are technical. Most of the time, they're not.

Planning

sebiwi — Mon, 25 Mar 2019 07:19:02 +0100

I love planning meetings. Specially when we're supposed to plan every single aspect of a product's lifetime for the next 25 years

Regex

sebiwi — Mon, 18 Mar 2019 07:19:02 +0100

I've heard people trying to evaluate performance by counting lines of code. That's attributing the same value to a variable assignment and a regular expression.

Datalake

sebiwi — Mon, 11 Mar 2019 07:19:02 +0100

Everyone talks about datalakes, no one talks about quality data. So almost every datalake looks like a shitpile.

OOM

sebiwi — Mon, 04 Mar 2019 07:19:02 +0100

The OOM killer is supposed to kill processes based on an OOM score. In reality, it just kills the Java application.

Agile says

sebiwi — Mon, 28 Jan 2019 07:19:02 +0100

Status feature

sebiwi — Mon, 21 Jan 2019 07:19:02 +0100

On Operations, DevOps and soft skills

sebiwi — Thu, 17 Jan 2019 07:19:02 +0100

Let’s talk about communication for a bit

One of the most interesting roles I’ve had to fulfill the last couple of years has been the “Operations guy working as a part of a Development team”. This is a fascinating situation to find yourself in. Allow me to elaborate.

Historically, Operations teams have been isolated from Development teams. Two separate organizational entities. The reasons for this were manifold: Operations people were a scarce resource, they needed to accommodate vast amounts of work for numerous Development teams (server provisioning for team A, middleware configuration for team B, application deployment for team C), it made sense for management to group people into teams using their skillset as sorting criteria… you name it. In the end, most interactions between Development teams and Operation teams happened through ticketing systems.

Effective communication

These workflows created and fueled most of the communication issues within organizations, and by doing so, created gargantuan bottlenecks on the development/deployment pipelines. Applications and services took months or even years to ship into production. This, needless to say, was frustrating for everyone involved in the process. It also had a huge impact on Time to Market. No one was happy.

While these situations still occur nowadays, the incorporation of Agile approaches into Software Development is becoming increasingly common, and its impact on Operations is clearly visible from an organisational point of view. It is not rare, for example, to see Feature Teams within an organization. These are cross-functional, which means that they tend to incorporate many different profiles into their ranks. From conception, design, and implementation, up to deployment, product owners and designers will be working hand in hand with developers. This most likely means that an OPS will also be a part of the team.

How is that a game changer?

When working as an OPS in a Development, Feature or Product team, most of your responsibilities will shift, whether you realize it or not. It will not be about taking team X’s artifact and deploying it on servers A, B and C anymore. It is your team now, and therefore, your artifact and your servers. You will most likely have to deal with a lot of things you are not used to dealing with.

This is a good thing. Embrace it.

It is an opportunity. If you do things right, you will be able to:

Use and apply your knowledge regarding technical architecture and systems. This may concern not only the application itself, but also every service or platform involved.
Facilitate discussions and answer questions regarding your areas of expertise. Once again, this not only includes the application, but also the components around it.
Show people what you do everyday, and how you do it. What’s the point of your work? Is it actually necessary? Isn’t it something that needs to be done only at the beginning of an application’s lifetime?
Improve the team’s dynamics: help them grow, and help them care. Don’t hold back: from good development practices applied to Operations, to workshops on existing processes.
Learn, to a vast extent.

Under this light, the role of an OPS inside a development team is virtually Tech Leading, focusing on operational aspects. In short, it’s mostly about soft skills (even though technical skills are still required), about the ability to express ideas, vulgarize subjects, solve issues, analyze and solve problems, and share knowledge with your team. That’s a tremendous change. And the basic ingredient for all of these is kindness.

On technical architecture

When working on an organizational setup like this, there is a high chance that you will be the most technical person on the team. When I say technical, I mean with the biggest background on Linux/Windows systems, middleware, networks and virtualisation. If not, that’s great news. It means that you will have people with whom you will be able to discuss all of these subjects. Someone who will be able to challenge you, or remind you what’s important when you’re having tunnel vision. In any case, you will most likely have to propose solutions to many different issues.

At some point you will have to deploy your application and its dependencies somewhere. That’s where your knowledge on the subject comes in. Web servers, application servers, reverse proxies, caching systems, databases, failover, high availability, disaster recovery… These are all things you will have to analyze. Should you use nginx or Apache? PostgreSQL or MySQL? The answer is always the same: it all depends on your needs. Try to analyze what you need before proposing a solution. Leverage your experience when doing so.

Be cautious: this does not mean that you need to make all of these decisions all by yourself. There are trade-offs for every single choice you will make. These trade-offs will not only impact the functioning of the application itself, but also its development. This means that their opinion on the matter is paramount. Your role is to explain the different options to the people that are concerned by the choice. Remember, consensus is key. Embrace challenge too. For good ideas, you need human interaction, healthy conflicts, argument and debate. When doing so, remember to be kind. Don’t impose your opinions on everyone else. Be constructive. And this is not specific for this section. There should be an acronym for this, RTBK. It should be used way more often than RTFM.

This also applies to Continuous Integration and Continuous Deployment. What is the simplest workflow in order to take the application’s source code, shape it into the actual application and make it accessible to users? This has tremendous value: it will allow you to automate time-consuming, repetitive tasks, creating a safe automated pipeline, which will in turn allow everyone to concentrate on delivering value. A piece of advice: start small, and work your way up to something that suits your needs. “Simple is better” should be your mantra. Once again, apply the knowledge acquired from previous experiences when doing so.

Improve, based on your experiences

On facilitating interactions

More often than not, people on your team will have questions regarding your field of expertise. Discussions will be held on subjects you know in depth. A lot of terms will be thrown around: availability, redundancy, stress testing, building and deployment. Once again, if they know everything there is to know about these subjects, that’s a good thing too. Either way, you might want to step in and catalyze the discussion.

Individuals and interactions over processes and tools

Before doing so, remember to be kind. It is a key aspect in human interaction, and it will encourage participation, collaboration, and innovation.

First off, explain the meaning of every concept being discussed to everyone. It is crucial for every single person on the team to share the same language in order to have effective interactions. When having discussions about the “bastion”, one person may be talking about the web interface of a Cloud provider, whereas another one might be talking about a Linux server.

Be clear with your communication. More specifically, work on your vulgarization. I can’t stress this enough. The ability to express complex concepts in a simple fashion is priceless. It’s one of the most valuable skills you can learn. They don’t necessarily need to know every single detail on the subject. It is not the same, saying “there was a problem with the application’s configuration” than “the application crashed because we forgot to set the heap’s maximum size”. A fundamental part of the vulgarization exercise is to be capable of discerning the appropriate level of technical depth for each person.

Sometimes, these discussions will start to consume the time allocated for other purposes: stand up meetings, retrospectives, backlog grooming or others. While it’s good to be able to facilitate these discussions, it is also important to find the right instances to do so. If they do not exist, you can propose new ones yourself. Or even better, just make yourself available in order to discuss these subjects. Individuals and interactions over processes and tools.

A large amount of people see Operations as an impenetrable affair. It is safe to say that it is a hard topic to grasp. This is mainly due to the huge amount of subjects it covers. Operations entails development, systems administration, networks and security, just to name a few. This may sound intimidating to most newcomers.

Nevertheless, this does not mean that they are not interested. They are often just scared of the unknown. Once people see that you are approachable, they will start asking questions. Even if they don’t, you should ask them if there are things that they want to learn. If things go right, you’ll get the opportunity to share your knowledge.

Before even thinking about doing so: RTBK. If you don’t know what this means, you’re skipping important parts of this article. Don’t. Go back, and take the time to read them.

There are two fundamental reasons to share your knowledge. First, mentoring people is one of the most interesting and rewarding things you can do. Motivated people have tremendous potential, and if they are willing to learn and are interested in what you do, you can catalyze their growth to a great extent. Sometimes it only takes a little push for someone to discover a great deal of capabilities. You just need to know how to give the right push, in the right direction.

Second, it allows you to spread the knowledge. If you’re the only person working on these subjects, you will most likely become a single point of failure. If something happens to what you built when you are not available to fix it, the whole system goes down. It is reasonable to want to share that responsibility with someone. Do not expect them to become fully autonomous, or a plug in replacement for you right away, they are already doing something else as a full-time job. Still, having enough knowledge to be able to debug common issues is already great.

Fullstack DevOps engineer

The most efficient form of knowledge sharing is pair programming. It is fundamental that everything that is going on is completely understood. You can’t expect people to pick up Infrastructure as Code without having any knowledge on Linux systems, for example. This is not necessarily an issue, as you can teach them as you go. Make sure they understand what’s going on, and do it often. Ask them to reformulate what you just said: drawing things works great for this purpose.

This is probably going to be a good exercise for you as well. Explaining a concept to someone forces you to structure it differently in your head, and it will allow you to know if you fully understand it too. If you do not, you can look up the answer together. This is not a problem. More on this in the next section.

Later on, you can give them tasks you would normally work on by yourself. When doing this, the most important part is to be able to select the right amount of work, with the right complexity. It must be challenging enough for them to feel excited, and not hard enough to make them frustrated. Aim for balance.

You can also use other formats in order to teach large groups of people at the same time. Mob programming works great too, or code katas, if you have interesting subjects you can share. You can teach them how to code their own wrappers using Test-Driven Development, how to test their infrastructure code, or how to leverage monitoring or reporting tools in order to understand what’s going on within your system.

On improving

Last but not least, you should contribute to the continuous improvement of the team. When doing so, remember to be kind. Make sure everyone on the team knows how important this is. It is a must-have quality when trying to improve as a whole, when proposing enhancements and giving feedback. Change your formulations, switch from “you made a mistake” to “we made a mistake”, it will help you stay away from finger pointing. Responsibilities should be collective.

It’s hard to be specific on this topic, since areas of improvement will vary from team to team. I’ll give it a try though.

At first, most people will refer to you as the DevOps of the team. Explain them that DevOps is not a role, but a culture of collaboration and communication. It should be a goal you should all aim for.

Fail, and fail fast, too. Champion innovation, testing new ideas, validating them, and cope with the fact that sometimes they don’t work. It’s a good thing, as long as you know when to seek an alternative, and you get to learn something.

Work on quality. Start doing code reviews, for example, if you are not doing them already, and include infrastructure code as well. They are most important when trying to see what people are doing, to correct or improve certain practices, and to share the code. Have them read your code too. At first they will be scared, and they will tell you that they don’t want to because they won’t have any remarks or contributions. This is not true. They will read it, and understand how it works. If they don’t, they can come over and ask for clarifications. No single points of failure.

Measure everything. Preach the importance of monitoring and observability. Let them know how to work on code instrumentation for it to be easily observable. Show them the benefits of having structured, clear logs, and being able to query the platform to have immediate answers on what is going on, at any time. They’ll be onboard as soon as you show them the advantages.

Lead by example. Motivate them, code with them, show them that you can do the same things you do in standard development when you’re doing Operations. Show them Clean Code, Test-Driven Development and refactoring, applied to infrastructure code.

Learn from errors and mistakes. If you have a production incident, analyze the root cause so that you can learn from it, and prevent it in the future. Asking yourself five times why something happened is a great way of finding root causes. You will often see that what you thought was a technical issue actually has an organizational or design root cause.

Say “I don’t know”, when you don’t know. You are not meant to know everything. Not knowing is not an issue. It is impossible to know everything. It is a good thing to say it. Be honest. People will trust you more, and start doing it themselves too.

“I don’t know”. Say it.

There’s no way I’m remembering all those things

You don’t have to. It all comes down to six basic principles:

Remember to be kind.
Use your power for the greater good.
Help people, explain things to them, resolve issues.
Share what you know.
Improve the team itself.
Remember to be kind.

And most importantly, have fun. If it’s not fun, it’s probably not worth it.

ESx

sebiwi — Mon, 14 Jan 2019 07:19:02 +0100

You can get a neat mathematical formula to calculate the real name of an ECMAScript. I double dare you to try to get the same thing with Windows.

Reality

sebiwi — Mon, 07 Jan 2019 07:19:02 +0100

There's a difference between the planning and our current progress. There must be an issue with reality. Certainly.

Retrospective

sebiwi — Mon, 31 Dec 2018 07:19:02 +0100

It's been a while since I started posting drawings in here. It's been fun. Maybe it's time for a little retrospective