PostgreSQL Statistics, Indexes, and Pareto Data Distributions
making.close.comWell, 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.