Re: Re: bgwriter changes
От | |
---|---|
Тема | Re: Re: bgwriter changes |
Дата | |
Msg-id | 28292295$110311607441c0372a69fd20.01065670@config6.schlund.de обсуждение исходный текст |
Список | pgsql-hackers |
Zeugswetter Andreas DAZ SD <ZeugswetterA@spardat.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
В списке pgsql-hackers по дате отправления: