Hi All,
We are having a reasonably powerful machine for supporting about 20
databases but in total they're not more then 4GB in size.
The machine is 2 processor 8 core and 8 Gig or ram so I would expect that PG
should cache the whole db into memory. Well actually it doesn't.
What is more
On Thu, Jun 18, 2009 at 08:27:02PM +0200, Peter Alban wrote:
Hi All,
We are having a reasonably powerful machine for supporting about 20
databases but in total they're not more then 4GB in size.
The machine is 2 processor 8 core and 8 Gig or ram so I would expect that PG
should cache the
So Ken ,
What do you reckon it should be ? What is the rule of thumb here ?
cheers,
Peter
On Thu, Jun 18, 2009 at 8:30 PM, Kenneth Marshall k...@rice.edu wrote:
On Thu, Jun 18, 2009 at 08:27:02PM +0200, Peter Alban wrote:
Hi All,
We are having a reasonably powerful machine for
On Thu, Jun 18, 2009 at 09:42:47PM +0200, Peter Alban wrote:
So Ken ,
What do you reckon it should be ? What is the rule of thumb here ?
cheers,
Peter
It really depends on your query mix. The key to remember is that
multiples (possibly many) of the work_mem value can be allocated
in an
What's still badgering me , is the performance when, there is no load or
significantly lower than peek times ?
Why is there such a big difference ?
i.e. off peek times a simple select with where (on indexed column) and limit
taks* 40 ms* during peek times it took *2 seconds* - 50 times slower
Peter Alban peter.alb...@gmail.com wrote:
Why is there such a big difference ?
i.e. off peek times a simple select with where (on indexed column)
and limit taks* 40 ms* during peek times it took *2 seconds* - 50
times slower !
If your high work_mem setting you may have been causing the
