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
