From: | Mark Wong <markwkm(at)gmail(dot)com> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Selena Deckelmann <selenamarie(at)gmail(dot)com>, Gabrielle Roth <gorthx(at)gmail(dot)com> |
Subject: | Re: dbt-2 tuning results with postgresql-8.3.5 |
Date: | 2009-02-22 23:03:28 |
Message-ID: | 70c01d1d0902221503i545cb533t99ee8fe5a275b44b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Jan 22, 2009 at 7:44 PM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> The next fine-tuning bit I'd normally apply in this situation is to see if
> increasing checkpoint_completion_target from the default (0.5) to 0.9 does
> anything to flatten out that response time graph. I've seen a modest
> increase in wal_buffers (from the default to, say, 1MB) help smooth out the
> rough spots too.
Hi all,
After yet another delay, I have .6 to .9 (I forgot .5. :():
http://pugs.postgresql.org/node/526
I don't think the effects of the checkpoint_completion_target are
significant, and I sort of feel it's because the entire database is on
a single device. I've started doing some runs with the database log
on a separate device, so I'll be trying some of these parameters
again.
Regards,
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Kouber Saparev | 2009-02-23 12:26:24 | LIMIT confuses the planner |
Previous Message | Grzegorz Jaśkiewicz | 2009-02-22 19:10:16 | Re: not in(subselect) in 8.4 |