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.
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.