Re: Possible explanations for catastrophic performace deterioration? - Mailing list pgsql-performance

From Jonah H. Harris
Subject Re: Possible explanations for catastrophic performace deterioration?
Date
Msg-id 36e682920709231224y3fb13ce3t9dd4217215c62bf7@mail.gmail.com
Whole thread Raw
In response to Re: Possible explanations for catastrophic performace deterioration?  (Carlos Moreno <moreno_pg@mochima.com>)
Responses Re: Possible explanations for catastrophic performance deterioration?
List pgsql-performance
On 9/23/07, Carlos Moreno <moreno_pg@mochima.com> wrote:
> Wait a second --- am I correct in understanding then that the bloating
> you guys are referring to occurs *in memory*??

No, bloating occurs on-disk; but this does affect memory.  Bloat means
that even though your table data may take up 1G after the initial
load, due to poor vacuuming, table layouts, etc. it to equal something
more... say 2G.

The thing is, even though the table only stores 1G of data, it is now
physically 2G.  So, anything that would need to read the entire table
(like COUNT(*)), or large sections of it sequentially, are performing
twice as many I/Os to do so.  Which means you're actually waiting on
two things, I/O and additional CPU time reading blocks that have very
little viable data in them.

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation                | fax: 732.331.1301
499 Thornall Street, 2nd Floor          | jonah.harris@enterprisedb.com
Edison, NJ 08837                        | http://www.enterprisedb.com/

pgsql-performance by date:

Previous
From: Carlos Moreno
Date:
Subject: Re: Possible explanations for catastrophic performace deterioration?
Next
From: Carlos Moreno
Date:
Subject: Re: Possible explanations for catastrophic performance deterioration?