From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Walker, James Les" <JAWalker(at)cantor(dot)com> |
Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Tuning Postgres 9.1 on Windows |
Date: | 2012-05-01 16:45:00 |
Message-ID: | CAHyXU0wAvR_vGa6AmZSgcZVo7foBoL4EoNCM1h3BCTBCn+dDvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, May 1, 2012 at 9:44 AM, Walker, James Les <JAWalker(at)cantor(dot)com> wrote:
> I installed the enterprisedb distribution and immediately saw a 400% performance increase. Turning off fsck made it an order of magnitude better. I'm now peaking at over 400 commits per second. Does that sound right?
yeah -- well it's hard to say but that sounds plausible based on what
i know. it would be helpful to see the queries you're running to get
apples to apples idea of what's going on.
> If I understand what you're saying, then to sustain this high rate I'm going to need a controller that can defer fsync requests from the host because it has some sort of battery backup that guarantees the full write.
yes -- historically, they way to get your tps rate up was to get a
battery backed cache. this can give you burst (although not
necessarily sustained) tps rates well above what the drive can handle.
lately, a few of the better built ssd also have on board capacitors
which provide a similar function and allow the drives to safely hit
high tps rates as well. take a good look at the intel 320 and 710
drives.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2012-05-01 17:00:02 | Re: Tuning Postgres 9.1 on Windows |
Previous Message | Clemens Eisserer | 2012-05-01 15:04:57 | Re: Any disadvantages of using =ANY(ARRAY()) instead of IN? |