Re: BUG #7519: incresed data base size and query performance lost

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: BUG #7519: incresed data base size and query performance lost
Дата
Msg-id 504722CD0200002500049EA5@gw.wicourts.gov
обсуждение исходный текст
Ответ на BUG #7519: incresed data base size and query performance lost  (lokendra.dixit@rmsi.com)
Список pgsql-bugs
"Lokendra Dixit" <Lokendra.Dixit@rmsi.com> wrote:

> RAM: 2 GB

You do realize how small that is for a database server, I hope.
Many people are walking around with cell phones in their pockets
that have a lot more.  This could contribute to severe slowdown with
even minimal growth of the database, as cached access will suddenly
become disk access, which is orders of magnitude slower.

> (Embedded image moved to file: pic00041.jpg)

It's much better to include such information in text form than to
use a screen image.

Anyway, according to that you didn't change autovacuum values from
the defaults.  You might want to make autovacuum a bit more
aggressive to try to keep table sizes down; but I think the root of
the problem is that a pg_dump and restore will normally pack the
data very tightly on disk.  In normal operations thing become less
tight as index pages split, etc., and you are probably going from a
very high cache hit ratio to a lower one, causing the slowdown.

For about $35 you could probably double or triple the amount of RAM
you have available and totally eliminate the problem.  You have
probably spent a lot more money on staff time to deal with the
problem than the RAM will cost.

-Kevin

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #7520: regexp_matches does not work as expected
Следующее
От: boy@atsc.nl
Дата:
Сообщение: BUG #7521: Cannot disable WAL log while using pg_dump