, Robert Haas wrote:
> On Sun, Jun 21, 2009 at 4:59 PM, Peter Alban
> wrote:
> >
> >
> > On Sun, Jun 21, 2009 at 10:01 PM, Justin Graf
> > wrote:
> >>
> >> Peter Alban wrote:
> >>
> >> duration: 2533.734 ms statement:
> >&g
On Sun, Jun 21, 2009 at 10:01 PM, Justin Graf wrote:
> Peter Alban wrote:
>
> *duration: 2533.734 ms statement: *
>
> *SELECT news.url_text,news.title, comments.name, comments.createdate,
> comments.user_id, comments.comment FROM news, comments WHERE comments.c
erations = 0 # selects default based on effort
#geqo_selection_bias = 2.0 # range 1.5-2.0
# - Other Planner Options -
#default_statistics_target = 10 # range 1-1000*
cheers,
Peter
On Sun, Jun 21, 2009 at 7:42 PM, Robert Haas wrote:
> On Sun, Jun 21,
Hey folks !
Still kind of analyzing the situation , I realized that I do have a
reasonably high shared_memory and effective_cache_size , though if the same
query is being run in a number of times ~100-200 concurrent connection it is
not being cached .
Should PG realize that if the table data is
lower !
cheers,
Peter
On Thu, Jun 18, 2009 at 10:01 PM, Kenneth Marshall wrote:
> 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
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 m
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
