Added to TODO:
* Consider wither increasing BM_MAX_USAGE_COUNT improves performance
http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php
---
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I don't really see why it's overkill.
Well I
On Jun 26, 2007, at 11:57 PM, Greg Smith wrote:
On Wed, 27 Jun 2007, ITAGAKI Takahiro wrote:
It might be good to use statistics information about buffer usage
to modify X runtime.
I have a complete set of working code that tracks buffer usage
statistics as the background writer scans, so
On Jun 28, 2007, at 7:55 AM, Greg Smith wrote:
On Thu, 28 Jun 2007, ITAGAKI Takahiro wrote:
Do you need to increase shared_buffers in such case?
If you have something going wild creating dirty buffers with a high
usage count faster than they are being written to disk, increasing
the size
Jim Nasby [EMAIL PROTECTED] writes:
Is this still a serious issue with LDC? I share Greg Stark's concern that
we're
going to end up wasting a lot of writes.
I think that's Greg Smith's concern. I do think it's something that needs to
be measured and watched for. It'll take some serious
On Fri, 29 Jun 2007, Jim Nasby wrote:
On Jun 26, 2007, at 11:57 PM, Greg Smith wrote:
I have a complete set of working code that tracks buffer usage
statistics...
Even if it's not used by bgwriter for self-tuning, having that information
available would be very useful for anyone trying to
On Thu, 28 Jun 2007, ITAGAKI Takahiro wrote:
Do you need to increase shared_buffers in such case?
If you have something going wild creating dirty buffers with a high usage
count faster than they are being written to disk, increasing the size of
the shared_buffers cache can just make the
Greg Smith [EMAIL PROTECTED] writes:
On Tue, 26 Jun 2007, Heikki Linnakangas wrote:
How much of the buffer cache do you think we should try to keep clean? And
how large a percentage of the buffer cache do you think have usage_count=0 at
any given point in time?
What I discovered is that
Tom Lane [EMAIL PROTECTED] writes:
I don't really see why it's overkill.
Well I think it may be overkill in that we'll be writing out buffers that
still have a decent chance of being hit again. Effectively what we'll be doing
in the approximated LRU queue is writing out any buffer that
Gregory Stark [EMAIL PROTECTED] writes:
If we find it's overkill then what we should consider doing is raising
BM_MAX_USAGE_COUNT. That's effectively tuning the percentage of the lru chain
that we decide we try to keep clean.
Yeah, I don't believe anyone has tried to do performance testing for
On Wed, 27 Jun 2007, Gregory Stark wrote:
I was seeing 90% dirty+usage_count0 in the really ugly spots.
You keep describing this as ugly but it sounds like a really good situation to
me. The higher that percentage the better your cache hit ratio is.
If your entire buffer cache is mostly
Greg Smith [EMAIL PROTECTED] wrote:
If your entire buffer cache is mostly filled with dirty buffers with high
usage counts, you are in for a long wait when you need new buffers
allocated and your next checkpoint is going to be traumatic.
Do you need to increase shared_buffers in such case?
On Tue, 26 Jun 2007, Tom Lane wrote:
It should try to be behind the sweep, ie, so far ahead that it's lapped
the clock sweep and is trailing along right behind it, cleaning buffers
immediately after their usage_count falls to zero. All the rest of the
buffer arena is either clean or has
Greg Smith [EMAIL PROTECTED] writes:
Unless someone else has a burning desire to implement Tom's idea faster
than me, I should be to build this new implementation myself in the next
couple of days.
Sure, go for it. I'm going to work next on committing the LDC patch,
but I'll try to avoid
Tom Lane wrote:
I just had an epiphany, I think.
As I wrote in the LDC discussion,
http://archives.postgresql.org/pgsql-patches/2007-06/msg00294.php
if the bgwriter's LRU-cleaning scan has advanced ahead of freelist.c's
clock sweep pointer, then any buffers between them are either clean,
or are
Greg Smith wrote:
I broke Itagaki-san's patch into two pieces when I was doing the review
cleanup on it specifically to make it easier to tinker with this part
without losing some of its other neat features. Heikki, did you do
anything with that LRU adjustment patch since I sent it out:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
Tom Lane wrote:
In fact, the notion of the bgwriter's cleaning scan being in front of
the clock sweep is entirely backward. It should try to be behind the
sweep, ie, so far ahead that it's lapped the clock sweep and is trailing
along right
On Tue, 26 Jun 2007, Heikki Linnakangas wrote:
How much of the buffer cache do you think we should try to keep
clean? And how large a percentage of the buffer cache do you think have
usage_count=0 at any given point in time?
What I discovered is that most of the really bad checkpoint pause
On Wed, 27 Jun 2007, ITAGAKI Takahiro wrote:
It might be good to use statistics information about buffer usage to
modify X runtime.
I have a complete set of working code that tracks buffer usage statistics
as the background writer scans, so that it has an idea what % of the
buffer cache is
On Tue, 26 Jun 2007, Heikki Linnakangas wrote:
I haven't worked on [Greg's] patch. I started looking at this, using
Itagaki's patch as the basis.
The main focus of how I reworked things was to integrate the whole thing
into the pg_stat_bgwriter mechanism. I thought that made the
20 matches
Mail list logo
