Re: Status of 8.3 patches - Mailing list pgsql-hackers

From ITAGAKI Takahiro
Subject Re: Status of 8.3 patches
Date
Msg-id 20070821100703.6D0C.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Re: Status of 8.3 patches  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Status of 8.3 patches  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
Heikki Linnakangas <heikki@enterprisedb.com> wrote:

> Bruce Momjian wrote:
> >   o  Automatic adjustment of bgwriter_lru_maxpages 
> > 
> >      We show this as waiting for performance results.  I am thinking we
> >      should hold this for 8.4.
> 
> Agreed. I spent close to a week trying different benchmarks and
> configurations and simple test cases on a test server and my laptop, and
> couldn't demonstrate bgwriter making a positive impact in any
> configuration I tried. The theory behind the patch is sound, but it
> looks like a lot more testing and analysis is needed.

Agreed, too.
However, I don't think it is a performance feature practically; it is just
for an advertisement: "We will be freed from the tuning of bgwriter in 8.3!"

Does anyone have a way to measure the performance difference by
bgwriter_lru_xxx ? I have no performance results not only of the patch
but also of those parameters. I'd like to use those test cases to compare
manual and automatic tunings of lru parameters for 8.4.


> >   o  Error correction for n_dead_tuples
> > 
> >      This shows as waiting on another patch.  Again, I am thinking to
> >      keep it for 8.4.
> 
> It was waiting on the "vacuum oldestxmin" patch, which didn't make it to
> 8.3. I don't care for the patch myself, but it was submitted well before
> feature freeze and deserves a review. It looks good to me at first glance.

I think there is no stopper to the patch, too.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: tsearch2 patch status report
Next
From: Andrew Dunstan
Date:
Subject: Re: tsearch2 patch status report