Peter Alban 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 OS to
discard cac
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 !
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
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 wrote:
> 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
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 cach
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 strange
