Re: Needed: Simplified guide to optimal memory - Mailing list pgsql-performance

From Todd Landfried
Subject Re: Needed: Simplified guide to optimal memory
Date
Msg-id 97CA7057-5DEE-4AA5-A4F3-8DEC1CAE720F@viatornetworks.com
Whole thread Raw
In response to Re: Needed: Simplified guide to optimal memory  (Mark Lewis <mark.lewis@mir3.com>)
Responses Re: Needed: Simplified guide to optimal memory
Re: Needed: Simplified guide to optimal memory
List pgsql-performance
Thanks for the link. I'll look into those.

I'm going only on what my engineers are telling me, but they say
upgrading breaks a lot of source code with some SQL commands that are
a pain to hunt down and kill. Not sure if that's true, but that's
what I'm told.

Todd

On Jun 16, 2005, at 10:01 AM, Mark Lewis wrote:


> We run the RPM's for RH 7.3 on our 7.2 install base with no problems.
> RPM's as recent as for PostgreSQL 7.4.2 are available here:
> ftp://ftp10.us.postgresql.org/pub/postgresql/binary/v7.4.2/redhat/
> redhat-7.3/
>
> Or you can always compile from source.  There isn't any such thing
> as a
> 'supported' package for RH7.2 anyway.
>
> -- Mark Lewis
>
>
> On Thu, 2005-06-16 at 07:46 -0700, Todd Landfried wrote:
>
>
>> Yes, it is 7.2. Why? because an older version of our software runs on
>> RH7.3 and that was the latest supported release of Postgresql for
>> RH7.3 (that we can find). We're currently ported to 8, but we still
>> have a large installed base with the other version.
>>
>>
>> On Jun 15, 2005, at 7:18 AM, Tom Lane wrote:
>>
>>
>>
>>> Dennis Bjorklund <db@zigo.dhs.org> writes:
>>>
>>>
>>>
>>>> On Wed, 15 Jun 2005, Todd Landfried wrote:
>>>>
>>>>
>>>>
>>>>> NOTICE:  shared_buffers is 256
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>> This looks like it's way too low. Try something like 2048.
>>>>
>>>>
>>>>
>>>
>>> It also is evidently PG 7.2 or before; SHOW's output hasn't looked
>>> like
>>> that in years.  Try a more recent release --- there's usually
>>> nontrivial
>>> performance improvements in each major release.
>>>
>>>             regards, tom lane
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 2: you can get off all lists at once with the unregister command
>>>     (send "unregister YourEmailAddressHere" to
>>> majordomo@postgresql.org)
>>>
>>>
>>>
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 9: the planner will ignore your desire to choose an index scan
>> if your
>>       joining column's datatypes do not match
>>
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
>



pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: How does the transaction buffer work?
Next
From: Tom Lane
Date:
Subject: Re: How to determine whether to VACUUM or CLUSTER