Added to TODO:
* Consider adding buffers the BGW finds reusable to the free list
http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php
* Automatically tune bgwriter_delay based on activity rather then using a
fixed interval
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Smith wrote:
I'm mostly done with my review of the Automatic adjustment of
bgwriter_lru_maxpages patch. In
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Smith wrote:
I'm mostly done with my review of the Automatic adjustment of
bgwriter_lru_maxpages patch. In
I'm mostly done with my review of the Automatic adjustment of
bgwriter_lru_maxpages patch. In addition to issues already brought up
with that code, there are some small things that need to be done to merge
it with the recent pg_stat_bgwriter patch, and I have some concerns about
its unbounded
On Wed, Apr 18, 2007 at 09:09:11AM -0400, Greg Smith wrote:
I'm mostly done with my review of the Automatic adjustment of
bgwriter_lru_maxpages patch. In addition to issues already brought up
with that code, there are some small things that need to be done to merge
it with the recent
Greg Smith [EMAIL PROTECTED] writes:
I'm mostly done with my review of the Automatic adjustment of
bgwriter_lru_maxpages patch. In addition to issues already brought up with
that code, there are some small things that need to be done to merge it with
the recent pg_stat_bgwriter patch, and I
Greg Smith [EMAIL PROTECTED] writes:
With the new patch, the LRU writer is fairly well bounded in that it
doesn't write out more than it thinks it will need; you shouldn't get into
a situation where many more pages are written than will be used in the
near future. Given that mindset,
Gregory Stark [EMAIL PROTECTED] writes:
I had a thought on this. Instead of sleeping for a constant amount of time and
then estimating the number of pages needed for that constant amount of time
perhaps what bgwriter should be doing is sleeping for a variable amount of
time and estimating the
Tom Lane [EMAIL PROTECTED] writes:
Why? What you're really trying to determine, I think, is the I/O load
imposed by the bgwriter, and pages-per-second seems a pretty natural
way to think about that; percentage of shared buffers not so much.
What I'm saying is that pages/s will vary from
On Wed, 18 Apr 2007, Tom Lane wrote:
Furthermore, if the page was dirty, then it's probably been accessed
more recently than adjacent pages that are clean, so preferentially
zapping just-written pages seems backwards.
The LRU background writer only writes out pages that have a usage_count of
On Wed, 18 Apr 2007, Jim C. Nasby wrote:
So if you make this change will BgBufferSync start incrementing
StrategyControl-nextVictimBuffer and decrementing buf-usage_count like
StrategyGetBuffer does now?
Something will need to keep advancing the nextVictimBuffer, I hadn't
really finished
On Wed, 18 Apr 2007, Gregory Stark wrote:
In particular I'm worried about what happens on a very busy cpu-bound
system where adjusting the sleep times would result in it deciding to
not sleep at all. On such a system sleeping for even 10ms might be too
long... Anyways, if we have a working
12 matches
Mail list logo
