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".
>
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 ha
"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 seriou
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 o
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 t
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 prob
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 ca
On Wed, 27 Jun 2007, Gregory Stark wrote:
I was seeing >90% dirty+usage_count>0 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 fi
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
"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
Greg Smith <[EMAIL PROTECTED]> writes:
> What may need to happen here is to add Tom's approach, but perhaps
> restrain it using the current auto-tuning LRU patch's method of estimating
> how many clean buffers are needed in the near future. Particularly on
> large buffer caches, the idea of get
"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 discover
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 performance
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 d
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 ca
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
> > alo
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:
http:
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 <[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 avoi
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 posit
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 pinned and/or have
22 matches
Mail list logo
