Alvaro Herrera wrote:
> On Tue, Sep 21, 2004 at 10:22:57AM -0400, Bruce Momjian wrote:
>
> > Added to open items list:
> >
> > * adjust bgwriter defaults, allow disabling
>
> Now that the oid2name patch has been applied, you can remove the
> oid2name item from the open items list.
Done.
>
On Tue, Sep 21, 2004 at 10:22:57AM -0400, Bruce Momjian wrote:
> Added to open items list:
>
> * adjust bgwriter defaults, allow disabling
Now that the oid2name patch has been applied, you can remove the
oid2name item from the open items list.
Additionaly, there's a patch in the patch que
Added to open items list:
* adjust bgwriter defaults, allow disabling
---
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > Setting the delay to the same value as checkpoint_timeout would effectiv
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Setting the delay to the same value as checkpoint_timeout would effectivly
> disable bgwriter between checkpoints. This is what I wanted.
> The problem is that this is currently not possible, since bgwriter_delay has
> an upper limit of 5 seconds. Tom
Bruce Momjian wrote:
> What about the original request to turn off the bgwriter? Would setting
> the delay to a very high value do that?
Setting the delay to the same value as checkpoint_timeout would effectivly
disable bgwriter between checkpoints. This is what I wanted.
The problem is that thi
What about the original request to turn off the bgwriter? Would setting
the delay to a very high value do that?
---
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> >>> bgwriter_delay = 50 (now default 200)
> >
Jan Wieck <[EMAIL PROTECTED]> writes:
>>> bgwriter_delay = 50 (now default 200)
>>> bgwriter_percent = 2(now default 1)
>>> bgwriter_maxpages = 200 (now default 100)
> Just what I was having the best TPC-C results with.
I'm a bit hesitant to reduce the default bgwriter_delay, since AFAICS
On 9/20/2004 2:02 AM, Michael Paesold wrote:
The bgwriter always flushes the oldest dirty buffers, and every buffer
touched (hit or faulted in). The output above doesn't tell you how many
buffers are really dirty. But if the system is under load, that is
pretty much the same as the distance between
Jan Wieck" <[EMAIL PROTECTED]>
> > Aside from that I don't believe that the output can answer questions
about
> > the efficiency of bgwriter...
> >
> > DEBUG: ARC T1target= 194 B1len= 779 T1len= 180 T2len= 820 B2len=
208
> > DEBUG: ARC total = 99% B1hit= 18% T1hit= 6% T2hit= 75% B2hit=
On 9/18/2004 8:38 AM, Michael Paesold wrote:
Tom Lane wrote:
There is some debug output available from the ARC code,
but I dunno if its output is actually useful ;-). Try
http://developer.postgresql.org/docs/postgres/runtime-config.html#GUC-DEBUG-SHARED-BUFFERS
"debug_shared_buffers (integer)
Num
Tom Lane wrote:
> There is some debug output available from the ARC code,
> but I dunno if its output is actually useful ;-). Try
>
>
http://developer.postgresql.org/docs/postgres/runtime-config.html#GUC-DEBUG-SHARED-BUFFERS
"debug_shared_buffers (integer)
Number of seconds between ARC reports.
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> Is there currently debug output in the code that could tell me answers to
> those questions?
There is some debug output available from the ARC code,
but I dunno if its output is actually useful ;-). Try
http://developer.postgresql.org/docs/postgres
Tom Lane wrote:
> You can't turn off the bgwriter process entirely anymore, because we
> rely on it for checkpoints. However I suppose there's no solid reason
> not to allow bgwriter_delay to be set as high as checkpoint_timeout,
> which would accomplish your goal of not spinning up the laptop dis
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> pgwriter is keeping my disks busy and disturbs me :-(. The more I like
> pgwriter for a production system, the less I like it on my desktop during
> developement.
> So I thought I would just be able to disable this, but that seems not the
> case.
You
14 matches
Mail list logo
