From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Bgwriter behavior |
Date: | 2005-01-02 06:02:09 |
Message-ID: | 200501020602.j02629n22398@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > o everyone agrees the current meaning of bgwriter_percent is
> > useless (percent of dirty buffers)
>
> Oh?
>
> It's not useless by any means; it's a perfectly reasonable and useful
> definition that happens to be expensive to implement. One of the
> questions that is not answered to my satisfaction is what is an adequate
> substitute that doesn't lose needed functionality.
I remembered this statement:
> I think there's a reasonable case to be made for redefining
> bgwriter_percent as the max percent of the total buffer list to scan
> (not the max percent of the list to return --- Jan correctly pointed out
> that the latter is useless). Then we could modify
> StrategyDirtyBufferList so that the percent and maxpages parameters are
> passed in, so it can stop as soon as either one is satisfied. This
> would be a fairly small/safe code change and I wouldn't have a problem
> doing it even at this late stage of the cycle.
Referenced here:
http://archives.postgresql.org/pgsql-hackers/2004-12/msg00703.php
But I now see that Jan was objecting to the idea of the previouis patch
where bgwriter_percent is a percent of all buffers to return, which we
just discussed as redundant.
> > o bgwriter_percent and bgwriter_maxpages are duplicate for a
> > given number of buffers and it isn't clear which one takes
> > precedence.
>
> Not unless the current definition of bgwriter_percent is changed.
>
> Please try to make sure that your summaries reduce confusion instead
> of increasing it.
OK, whatever. My point is that many have critisized the current
behavior of bgwriter_percent and I haven't heard anyone defend it,
including Jan.
What bothers me is that we have known bgwriter needs tuning for months
and I am not sure we are any closer to improving it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2005-01-02 07:55:42 | Re: TODO item: make world safe for spaces in build/install |
Previous Message | Korry | 2005-01-02 00:30:08 | Re: exception handling in plpgsql |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2005-01-02 14:18:21 | Re: Allow pooled connections to list all prepared queries |
Previous Message | lsunley | 2005-01-01 23:50:21 | psql session log |