From: | <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Zeugswetter Andreas DAZ SD <ZeugswetterA(at)spardat(dot)at> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: bgwriter changes |
Date: | 2004-12-15 13:24:02 |
Message-ID: | 28292295$110311607441c0372a69fd20.01065670@config6.schlund.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zeugswetter Andreas DAZ SD <ZeugswetterA(at)spardat(dot)at> wrote on
15.12.2004, 11:39:44:
>
> > > > and stops early when eighter maxpages is reached or bgwriter_percent
> > > > pages are scanned ?
> > >
> > > Only if you redefine the meaning of bgwriter_percent. At present it's
> > > defined by reference to the total number of dirty pages, and that can't
> > > be known without collecting them all.
> > >
> > > If it were, say, a percentage of the total length of the T1/T2 lists,
> > > then we'd have some chance of stopping the scan early.
> >
> > ...which was exactly what was proposed for option (3).
>
> But the benchmark run was with bgwriter_percent 100.
Yes, it was for run 211, but the patch that was used effectively
disabled bgwriter_percent in favour of looking only at
bgwriter_maxpages.
The patch used was not exactly what was being discussed here. In that
patch, StrategyDirtyBufferList scans until it find bgwriter_maxpages
dirty pages, then stops. That means a varying number of buffers on the
list are scanned, starting from the LRU.
What is being suggested here was implemented for bg2.patch. The
algorithm in there was for StrategyDirtyBufferList to scan until it had
looked at the dirty/clean status of bgwriter_maxpages buffers. That
means a constant number of buffers on the list are scanned, starting
from the LRU.
The two alternative algorithms are similar, but have these differences:
The former (option (2)) finds a constant number of dirty pages, though
has varying search time. The latter (option (3)) has constant search
time, yet finds a varying number of dirty pages. Both alternatives
avoid scanning the whole of the buffer list, as is the case in 8.0RC1,
allowing the bgwriter to act more frequently at lower cost.
There's some evidence that the second algorithm may be better, but may
have other characteristics or side-effects that we don't yet know. So
At this stage of the game, I'm happier not to progress option (3) any
further for r8.0, since option(2) is closest to the one that has been
through beta-testing.
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-12-15 13:47:38 | strange regression failure |
Previous Message | Zeugswetter Andreas DAZ SD | 2004-12-15 10:39:44 | Re: bgwriter changes |