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
>
>
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? |