Re: checkpoint patches

On Sun, Mar 25, 2012 at 4:29 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> I wouldn't be too quick to dismiss increasing checkpoint frequency (ie:
> decreasing checkpoint_timeout).

I'm not dismissing that, but my tests show only a very small gain in
that area. Now there may be another test where it shows a bigger
gain, but finding such a test is the patch author's job, not mine.
Patches that supposedly improve performance should be submitted with
test results showing that they do. This patch was submitted more than
two months ago with no performance results, no documentation, and
bugs. Because I feel that this is an important area for us to try to
improve, I devoted a substantial amount of time to trying to
demonstrate that the patch does something good, but I didn't find
anything very convincing, so I think it's time to punt this one for
now and let Greg pursue the strategy he originally intended, which was
to "leave this whole area alone until 9.3"[1]. I think he only
submitted something at all because I kicked out a somewhat random
attempt to solve the same problem[2]. Well, it turns out that, on the
test cases I have available, neither one is any great shakes.
Considering Greg Smith's long track record of ridiculously diligent
research, I feel pretty confident he'll eventually come back to the
table either with more evidence that this is the right approach (in
which case we'll be able to document it in a reasonable way, which is
currently impossible, since we don't have only the vaguest idea when
setting it to a non-zero value might be useful, or what value to set)
or with another proposed approach that he thinks is better and test
results to back it up. Had someone other than Greg proposed this, I
probably wouldn't have spent time on it at all, because by his own
admission it's not really ready for prime time, but as it was I
thought I'd try to see if I could fill in the gaps.

Long story short, this may yet prove to be useful in some
as-yet-unknown set of circumstances, but that's not a sufficient
reason to commit it, so I've marked it (and my patch, which doesn't
win either) Returned with Feedback.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[1] http://archives.postgresql.org/message-id/4F13D856.60704@2ndQuadrant.com
[2] https://commitfest.postgresql.org/action/patch_view?id=752