On 12/9/15 7:59 PM, Berend Tober wrote:
The issue is that I'd like the application (that is, the data base and its stored procedures) to be robust enough to be a "long-running" application, i.e. one that doesn't suffer gradual performance degradation as time and the accumulated data increase.
In my experience, no such thing exists. This is one of the things that makes database development very different than other forms of programming. Once you write a program, it's basically always going to perform the same. Database performance slowly changes over time, not only due to different amounts of data, but also different *composition* of data stored.
Of course, it is wise to avoid things that will obviously hurt future performance, so it's good that you're thinking about this. But don't expect something you can "set and forget". :)
This question was sort of addressed at the "query tuning" aspect, and I'm confident that partitioning would help.
Keep in mind that partitioning isn't a magic bullet either, though in this case I agree it would help. Sometimes something as simple as having "active" and "history" partitions is enough.
This project is a game, btw, described at
You might be interested in https://schemaverse.com/ -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
