From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Autotuning Group Commit |
Date: | 2005-01-22 06:18:07 |
Message-ID: | 20050122061807.GI67721@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
1) I'm in favor of autotuning anything possible.
2) In addition to turning group_commit on and off, what about also
adjusting the commit delay, based on statistics of recent commits? It
might require a slightly larger sample set (maybe the last 100 commits),
but it seems it would provide more flexibility (hence more usefulness)
to the autotuning.
I belive you'd want to first calculate the elapsed time between each
commit in the sample set, then look for groupings of elapsed time. If
you have a set that looks like this:
Time (ms) Number
2 *
4 *
6
8 **
10 *
12 ******
14 ****
16 **
18
20 *
then you'd want a delay of 16ms. I think this calculation could be done
fairly quickly by grouping the commits into buckets of different elapsed
times, then look for the largest elapsed time that has a number of
commits greater than the mean number of commits for all the buckets. But
I'm not a statistician, hopefully someone here is. :)
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-01-22 08:47:37 | Re: Autotuning Group Commit |
Previous Message | Jim C. Nasby | 2005-01-22 06:01:26 | Re: Extending System Views: proposal for 8.1/8.2 |