[development] table vs tables

Mark Fredrickson mark.m.fredrickson at gmail.com
Fri Sep 7 15:20:27 UTC 2007

> The "obvious" way to break up the table would be to use 1000 a smaller
> tables, but too many tables can also cause a problem.

You might also look at table partitioning:


Basically, it splits one tall table into many, smaller chunks that
look and behave like a single table. So you don't have to change your
queries but you could possibly get some performance benefits by not
having to scan or load as much of a table into memory.

I'm not a DBA, so I don't know how this really ends up working in
practice, but that's the theory at least.


More information about the development mailing list