On Die, 2002-11-19 at 09:08, Brion Vibber wrote:
I think it was once suggested that breaking the page
counters to a
separate table (two numeric columns, ID and count) might be a good idea.
It would probably help with our current configuration. If we really want
to make the switch to PostgreSQL, it can't harm.
We could also use the InnoDB plugin. Both Slashdot and K5 use it for
performance reasons, and it shouldn't require us to modify much/any
code. Besides better locking, it could provide huge performance benefits
because of its caching.
http://www.mysql.com/doc/en/InnoDB_overview.html
InnoDB provides MySQL with a transaction-safe (ACID compliant) table
handler with commit, rollback, and crash recovery capabilities. InnoDB
does locking on row level and also provides an Oracle-style consistent
non-locking read in SELECTs. These features increase multiuser
concurrency and performance. There is no need for lock escalation in
InnoDB, because row level locks in InnoDB fit in very small space.
InnoDB tables support FOREIGN KEY constraints as the first table type in
MySQL.
InnoDB has been designed for maximum performance when processing large
data volumes. Its CPU efficiency is probably not matched by any other
disk-based relational database engine.
Technically, InnoDB is a complete database backend placed under MySQL.
InnoDB has its own buffer pool for caching data and indexes in main
memory. InnoDB stores its tables and indexes in a tablespace, which may
consist of several files. This is different from, for example, MyISAM
tables where each table is stored as a separate file. InnoDB tables can
be of any size also on those operating systems where file-size is
limited to 2 GB.
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS -
http://www.berlios.de