On Tue, 2007-05-08 at 23:31 -0400, Greg Smith wrote:
>
> My issue wasn't with the idea, it was with the implementation. When I
> have my newbie hat on, it adds a layer of complexity that isn't needed for
> simple installs.
I find it very hard to agree with that.
As a newbie I install postgres
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
On Fri, May 11, 2007 at 01:25:04PM -0400, Alvaro Herrera wrote:
> Guillaume Cottenceau wrote:
> > Guillaume Cottenceau 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 s
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 t
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
inact
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);
- i
