Re: help tuning queries on large database

From: Mark Lewis
Subject: Re: help tuning queries on large database
Date: ,
Msg-id: 1136939286.22590.27.camel@archimedes
(view: Whole thread, Raw)
In response to: Re: help tuning queries on large database  (Ron)
Responses: Re: help tuning queries on large database  (Ron)
List: pgsql-performance

Tree view

help tuning queries on large database  (peter royal, )
 Re: help tuning queries on large database  (Tom Lane, )
  Re: help tuning queries on large database  (David Lang, )
 Re: help tuning queries on large database  (Harry Jackson, )
 Re: help tuning queries on large database  ("Luke Lonergan", )
  Re: help tuning queries on large database  (peter royal, )
   Re: help tuning queries on large database  ("Luke Lonergan", )
    Re: help tuning queries on large database  (peter royal, )
     Re: help tuning queries on large database  ("Luke Lonergan", )
   Re: help tuning queries on large database  (Ron, )
 Re: help tuning queries on large database  (Ron, )
  Re: help tuning queries on large database  (Kelly Burkhart, )
   Re: help tuning queries on large database  (Harry Jackson, )
  Re: help tuning queries on large database  (Mark Lewis, )
   Re: help tuning queries on large database  (Ron, )

Ron,

A few days back you mentioned:

> Upgrade your kernel to at least  2.6.12
> There's a known issue with earlier versions of the 2.6.x kernel and
> 64b CPUs like the Opteron.  See kernel.org for details.
>

I did some searching and couldn't find any obvious mention of this issue
(I gave up after searching through the first few hundred instances of
"64" in the 2.6.12 changelog).

Would you mind being a little more specific about which issue you're
talking about?  We're about to deploy some new 16GB RAM Opteron DB
servers and I'd like to check and make sure RH backported whatever the
fix was to their current RHEL4 kernel.

Thanks,
Mark Lewis


pgsql-performance by date:

From: "Dave Dutcher"
Date:
Subject: Left Join Performance vs Inner Join Performance
From: Tom Lane
Date:
Subject: Re: NOT LIKE much faster than LIKE?