Greg Smith <gsmith@gregsmith.com> writes:
> As the person who was complaining about corner cases I'm not in a position
> to talk more explicitly about, I can at least summarize my opinion of how
> I feel everyone should be thinking about this patch and you can take what
> you want from that.
Sorry, but we're not going to make decisions on the basis of evidence
you won't show us. Right at the moment the best thing to do seems to
be to enable LDC with a low minimum write rate and a high target
duration, and remove the thereby-obsoleted "all buffers" scan of the
existing bgwriter logic. If you've got specific evidence why any of
these things need to be parameterized, let's see it. Personally I think
that we have a bad track record of exposing GUC variables as a
substitute for understanding performance issues at the start, and this
approach isn't doing any favors for DBAs.
> Whether or not I think this is an awesome idea, the very idea of a change
> that big at this point gives me the willies. Just off the top of my head,
> there's a whole class of issues involving recycling xlog segments this
> would introduce I would be really unhappy with the implications of.
Really? Name one. AFAICS this should not affect xlog recycling in the
slightest (other than that we have to bump up the target number of live
segments from 2x to 3x the checkpoint distance).
> Did anyone else ever notice that when a new xlog segment is created,
> the write to clear it out doesn't happen via direct I/O like the rest
> of the xlog writes do?
It's not supposed to matter, because that path isn't supposed to be
taken often.
regards, tom lane
