On Thu, 2004-07-22 at 00:35, Gavin Sherry wrote:
> On Wed, 21 Jul 2004, Simon Riggs wrote:
>
> > I notice this:
> >
> > When a checkpoint occurs, if a log file is more than 75% full then a new
> > file will be allocated (in PreallocXlogFiles).
> >
> > This assumes we checkpoint at least 4 times per log file, otherwise it
> > will be effectively random whether we actually ever do this or not. With
> > an uneven or bursty workload, we would need to checkpoint many more
> > times per xlog to even notice this is ever being called. (I never have).
> >
> > ...but we don't check that anywhere in the code.
>
> I prefer the idea of just checking it more often than pulling the code out
> all together. I think this sits well with Jan's work on consistent
> availability (buffer manager, vacuum delay).
>
Good idea. Hey - we could get archiver to do this, seeing as it knows
when the logs are full. Just do: I've seen a full one, I'll prealloc
another. No test, just alloc. (Or the bgwriter...)
On Thu, 2004-07-22 at 00:53, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I would like to remove PreallocXlogFiles on the basis that it is dead,
> > or at least pointless code.
>
> I wonder whether we should not put back the preallocated-files GUC
> parameter that Bruce took out a release or two back. PreallocXlogFiles
> made a lot more sense back when that parameter existed.
That's simplest, especially if the code is there.
But again, if you set it to a constant value it's not really responding
to system demands, its just the admin's guess of what to set it to.
Gavin's idea sounds more optimal...
However, I'm not at all convinced that this analysis holds up with
> bursty traffic or when the archiver is delaying rotation of old xlogs.
> If the number of physical WAL files needs to grow and shrink because
> of such effects, then PreallocXlogFiles is the only thing that can
> prevent foreground processes from having to do the work that should
> be handled by the checkpointer.
Yes, I agree, but the checkpointer isn't waking up often enough
currently to do this effectively. It's just randomly doing it.
Best regards, Simon Riggs
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
