From: | Christopher Petrilli <petrilli(at)gmail(dot)com> |
---|---|
To: | Vivek Khera <vivek(at)khera(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Impact of checkpoint_segments under continual load conditions |
Date: | 2005-07-18 18:45:35 |
Message-ID: | 59d991c405071811457ccdd3f1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 7/18/05, Vivek Khera <vivek(at)khera(dot)org> wrote:
>
> On Jul 17, 2005, at 1:08 PM, Christopher Petrilli wrote:
>
> > Normally, checkpoint_segments can help absorb some of that, but my
> > experience is that if I crank the number up, it simply delays the
> > impact, and when it occurs, it takes a VERY long time (minutes) to
> > clear.
>
> There comes a point where your only recourse is to throw hardware at
> the problem. I would suspect that getting faster disks and splitting
> the checkpoint log to its own RAID partition would help you here.
> Adding more RAM while you're at it always does wonders for me :-)
My concern is less with absolute performance, than with the nosedive
it goes into. I published some of my earlier findings and comparisons
on my blog, but there's a graph here:
http://blog.amber.org/diagrams/comparison_mysql_pgsql.png
Notice the VERY steep drop off. I'm still trying to get rid of it,
but honestly, am not smart enough to know where it's originating. I
have no desire to ever use MySQL, but it is a reference point, and
since I don't particularly need transactional integrity, a valid
comparison.
Chris
--
| Christopher Petrilli
| petrilli(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Dario | 2005-07-18 19:24:19 | Re: join and query planner |
Previous Message | Vivek Khera | 2005-07-18 18:32:14 | Re: Impact of checkpoint_segments under continual load conditions |