The following bug has been logged online:
Bug reference: 4575
Logged by: Scott Carey
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.5, 8.3.4
Operating system: Linux (CentOS 5.2 2.6.18-92.1.10.el5)
Description:All page cache in shared_buffers pinned
nt: Thursday, December 11, 2008 12:35 AM
To: Scott Carey
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4575: All page cache in shared_buffers pinned
(duplicated by OS, always)
On Thu, Dec 11, 2008 at 5:37 AM, Scott Carey wrote:
>
>
> Run top, and note the largest value o
_
From: Tom Lane [...@sss.pgh.pa.us]
Sent: Thursday, December 11, 2008 5:57 AM
To: Scott Carey
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4575: All page cache in shared_buffers pinned
(duplicated by OS, always)
"Scott Carey" writes:
> I
in that
realm. Now that I am comfortable that you understand the symptoms I see, and
you are confident its elsewhere, I trust that the issue's cause must be
elsewhere.
Thanks!
-Scott
On 12/11/08 1:16 PM, "Tom Lane" wrote:
Scott Carey writes:
> I am 99.9% certian its not a
Linux, CentOS 5.2, Postgres 8.3.4, 8.3.5. System tables and user tables listed
below have been VACUUM'd, ANALYZE'd and REINDEX'd.
Summary:
Simple update / delete queries that hit a parent table façade of a large
partitioned database are taking 15 to 20 seconds to plan (and a couple ms to
exec
The following bug has been logged online:
Bug reference: 4264
Logged by: Scott Carey
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Linux (CentOS)
Description:Optimizer fails to use hash_aggregate when appropriate.
Details:
The query
query planner Tom,
and the reminder that DISTINCT forces a sort -- I forgot all about that.
-Scott Carey
On Wed, Jun 25, 2008 at 1:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Scott Carey" <[EMAIL PROTECTED]> writes:
> > The query optimizer fails to use a hash ag
