Added to TODO:
* Test to see if calling PreallocXlogFiles() from the background writer
will help with WAL segment creation latency
http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php
---
Tom Lane wrote:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Here's latest revision of Itagaki-sans Load Dist
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> While thinking about this, I made an observation on full_page_writes.
> Currently, we perform a full page write whenever LSN < RedoRecPtr. If
> we're clever, we can skip or defer some of the full page writes:
I'm not convinced this is safe; in par
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> For 8.3, we should probably just do some simple compensation in the checkpoint
> throttling code, if we want to do anything at all. But this is something to
> think about in the future.
Just as a stress test it might be interesting to run a quic
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Heikki Linnakangas wrote:
For comparison, imola-328 has full_page_writes=off. Checkpoints last ~9
minutes there, and the graphs look very smooth. That suggests that
spreading the writes over a longer time wouldn't make a difference, but
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> For comparison, imola-328 has full_page_writes=off. Checkpoints last ~9
>> minutes there, and the graphs look very smooth. That suggests that
>> spreading the writes over a longer time wouldn't make a difference, but
>> smo
Heikki Linnakangas wrote:
> For comparison, imola-328 has full_page_writes=off. Checkpoints last ~9
> minutes there, and the graphs look very smooth. That suggests that
> spreading the writes over a longer time wouldn't make a difference, but
> smoothing the rush at the beginning of checkpoint m
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I'm scheduling more DBT-2 tests at a high # of warehouses per Greg
Smith's suggestion just to see what happens, but I doubt that will
change my mind on the above decisions.
When do you expect to have tho
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The comment in PreallocXlogFiles is out of date:
Yeah, I changed it yesterday ...
> As you pointed out, it only preallocates one log file. And there is no
> XLOGfile mentioned anywhere else in the source tree.
If memory serves, there once was a v
On Wed, 27 Jun 2007, Tom Lane wrote:
Also, the question of redesigning the bgwriter's LRU scan is
still open. I believe that's on Greg's plate, too.
Greg's plate was temporarily fried after his house was hit by lightening
yesterday. I just got everything back on-line again, so no coding
pr
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Here's latest revision of Itagaki-sans Load Distributed Checkpoints patch:
Applied with some minor revisions to make some of the internal APIs a
bit cleaner; mostly, it seemed like a good idea to replace all those
bool parameters w
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's latest revision of Itagaki-sans Load Distributed Checkpoints patch:
Applied with some minor revisions to make some of the internal APIs a
bit cleaner; mostly, it seemed like a good idea to replace all those
bool parameters with a flag-bits ap
On Tue, 26 Jun 2007, Heikki Linnakangas wrote:
I'm scheduling more DBT-2 tests at a high # of warehouses per Greg Smith's
suggestion just to see what happens, but I doubt that will change my mind on
the above decisions.
I don't either, at worst I'd expect a small documentation update perhaps
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
We could just allow any value up to 1.0, and note in the docs that you
should leave some headroom, unless you don't mind starting the next
checkpoint a bit late. That actually sounds pretty good.
Yeah, that sounds fine. There isn
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> We could just allow any value up to 1.0, and note in the docs that you
> should leave some headroom, unless you don't mind starting the next
> checkpoint a bit late. That actually sounds pretty good.
Yeah, that sounds fine. There isn't actually a
On Tue, 26 Jun 2007, Gregory Stark wrote:
What exactly happens if a checkpoint takes so long that the next checkpoint
starts. Aside from it not actually helping is there much reason to avoid this
situation? Have we ever actually tested it?
More segments get created, and because of how they are
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
We could just allow any value up to 1.0, and note in the docs that you should
leave some headroom, unless you don't mind starting the next checkpoint a bit
late. That actually sounds pretty good.
What exactly happens if a c
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> We could just allow any value up to 1.0, and note in the docs that you should
> leave some headroom, unless you don't mind starting the next checkpoint a bit
> late. That actually sounds pretty good.
What exactly happens if a checkpoint takes so
Michael Glaesemann wrote:
On Jun 26, 2007, at 13:49 , Heikki Linnakangas wrote:
Maximum is 0.9, to leave some headroom for fsync and any other things
that need to happen during a checkpoint.
I think it might be more user-friendly to make the maximum 1 (meaning as
much smoothing as you could
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Barring any objections from committer, I'm finished with this patch.
Sounds great, I'll start looking this over.
I'm scheduling more DBT-2 tests at a high # of warehouses per Greg
Smith's suggestion just to see what happens, but
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Barring any objections from committer, I'm finished with this patch.
Sounds great, I'll start looking this over.
> I'm scheduling more DBT-2 tests at a high # of warehouses per Greg
> Smith's suggestion just to see what happens, but I doubt that w
On Jun 26, 2007, at 13:49 , Heikki Linnakangas wrote:
Maximum is 0.9, to leave some headroom for fsync and any other
things that need to happen during a checkpoint.
I think it might be more user-friendly to make the maximum 1 (meaning
as much smoothing as you could possibly get) and intern
22 matches
Mail list logo
