From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Lokendra Dixit" <Lokendra(dot)Dixit(at)rmsi(dot)com> |
Cc: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #7519: incresed data base size and query performance lost |
Date: | 2012-09-05 15:00:45 |
Message-ID: | 504722CD0200002500049EA5@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Lokendra Dixit" <Lokendra(dot)Dixit(at)rmsi(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2012-09-05 20:48:28 | Re: BUG #7516: PL/Perl crash |
Previous Message | boy | 2012-09-05 13:57:12 | BUG #7521: Cannot disable WAL log while using pg_dump |