From: | Brendan Duddridge <brendan(at)clickspace(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Query using SeqScan instead of IndexScan |
Date: | 2006-04-03 04:20:00 |
Message-ID: | D2D8034B-4619-4D2A-93E3-BA7FA8FBA98E@clickspace.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi Josh,
Thanks. I've adjusted my effective_cache_size to 5 GB, so we'll see
how that goes.
I'm also doing some query and de-normalization optimizations so we'll
see how those go too.
____________________________________________________________________
Brendan Duddridge | CTO | 403-277-5591 x24 | brendan(at)clickspace(dot)com
ClickSpace Interactive Inc.
Suite L100, 239 - 10th Ave. SE
Calgary, AB T2G 0V9
On Apr 2, 2006, at 4:30 PM, Josh Berkus wrote:
> Brendan,
>
>> But just as a follow up question to your #1 suggestion, I have 8 GB
>> of ram in my production server. You're saying to set the
>> effective_cache_size then to 5 GB roughly? Somewhere around 655360?
>> Currently it is set to 65535. Is that something that's OS dependent?
>> I'm not sure how much memory my server sets aside for disk caching.
>
> Yes, about. It's really a judgement call; you're looking for the
> approximate
> combined RAM available for disk caching and shared mem. However,
> this is
> just used as a way of estimating the probability that the data you
> want is
> cached in memory, so you're just trying to be order-of-magnitude
> accurate,
> not to-the-MB accurate.
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
From | Date | Subject | |
---|---|---|---|
Next Message | Niklas Johansson | 2006-04-03 09:04:25 | Re: Trigger vs Rule |
Previous Message | Josh Berkus | 2006-04-02 22:30:55 | Re: Query using SeqScan instead of IndexScan |