Re: Needed: Simplified guide to optimal memory

From: Todd Landfried <tlandfried(at)viatornetworks(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Needed: Simplified guide to optimal memory
Date: 2005-06-17 02:15:08
Message-ID: 97CA7057-5DEE-4AA5-A4F3-8DEC1CAE720F@viatornetworks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)zigo(dot)dhs(dot)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(at)postgresql(dot)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
>
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-06-17 03:47:33 Re: How to determine whether to VACUUM or CLUSTER
Previous Message Josh Berkus 2005-06-16 21:53:36 Re: How does the transaction buffer work?