Well, what came to my head pretty quickly when reading this was "there should be separate tables";) Thank you for the article, I didn't know about the statistic configuration in postgres. I can use your lesson straight away, as I'm desining a database for online gaming platform and now I'm sure that there should be separate tables for currently running and finished games:)

Also: very clear and easy to follow language, props to the author. Cheers.

Good intuition and thank you! :) Not sure if this is a good fit for you, but you could consider using the partitioning built into Postgres to split one large logical table with all your games into a "hot" partition containing the currently running games and a "cold" partition containing your finished games.

https://www.postgresql.org/docs/current/ddl-partitioning.htm...

I will take a look, thanks :)

Hi HN community, author of the post here. Let me know please if you have any questions, comments, or feedback!

One of the best articles I've seen on here this year! I didn't know about the existence of `pg_hint_plan`.

Thank you very much! :) I still advise that you try really, really hard to avoid using `pg_hint_plan` if you can, but it's nice that it exists if all else fails or if you need temporary relief at a time of crisis.

It’s amazing how many of those types of problems are easily avoided or solved with event sourcing and CQRS.

Agreed, event sourcing is a pretty good match for call flows. You could first store every call leg / conference / recording / etc. webhook Twilio sends you as an event and then derive the state of the final "call" concept from those pieces of data.