Hi guys,
I'm looking for a database+hardware solution which should be able
to handle up to 500 requests per second. The requests will consist in:
- single row updates in indexed tables (the WHERE clauses will use
the index(es), the updated column(s) will not be indexed);
-
We're in the process of upgrading our db server's memory from 2GB to 8GB to
improve access performance. This is a dedicated dual Xeon db server not
running any significant non-db processes. Our database size on disk is
~11GB, although we expect it to grow to ~20GB. Much of this data is
Michael van Rooyen wrote:
I have no idea regarding the inner working of the pg's shared cache, but
what I would like to find out is whether it is table-row-based, or
disk-block-based.
It's block based.
In the case of it being disk-block based, my
inclination would be to let the kernel do
On Fri, May 11, 2007 at 01:25:04PM -0400, Alvaro Herrera wrote:
Guillaume Cottenceau wrote:
Guillaume Cottenceau gc 'at' mnc.ch writes:
With that in mind, I've tried to estimate how much benefit would
be brought by running VACUUM FULL, with the output of VACUUM
VERBOSE. However, it
On Sat, May 12, 2007 at 03:28:45PM +0100, Heikki Linnakangas wrote:
In the case of it being disk-block based, my
inclination would be to let the kernel do the buffering. In the case of
the cache being table-row-based, I would expect it to be much more
space-efficient and I would be
