Re: Possible explanations for catastrophic performace deterioration?

Поиск
Список
Период
Сортировка
От Jonah H. Harris
Тема Re: Possible explanations for catastrophic performace deterioration?
Дата
Msg-id 36e682920709231224y3fb13ce3t9dd4217215c62bf7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possible explanations for catastrophic performace deterioration?  (Carlos Moreno <moreno_pg@mochima.com>)
Ответы Re: Possible explanations for catastrophic performance deterioration?  (Carlos Moreno <moreno_pg@mochima.com>)
Список 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 по дате отправления:

Предыдущее
От: Carlos Moreno
Дата:
Сообщение: Re: Possible explanations for catastrophic performace deterioration?
Следующее
От: Carlos Moreno
Дата:
Сообщение: Re: Possible explanations for catastrophic performance deterioration?