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
http://archives.postgresql.org/pgsql-hackers/2007-04
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.
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.
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 pat
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 im
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
"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 fro
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
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,
"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 pat
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
11 matches
Mail list logo
