Re: dbt-2 tuning results with postgresql-8.3.5

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

In response to

Browse pgsql-performance by date

  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