On Fri, 6 Apr 2007, Takayuki Tsunakawa wrote:
could anyone evaluate O_SYNC approach again that commercial databases
use and tell me if and why PostgreSQL's fsync() approach is better than
theirs?
I noticed a big improvement switching the WAL to use O_SYNC (+O_DIRECT)
instead of fsync on my b
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> The patches look good to me.
Please commit whatever you think is reasonable.
> BTW, is anybody working on enabling the fill factor to the tables used
> by pgbench? 8.3 will introduce HOT, and I think adding the feature
> will make it easier to test HOT.
On Thu, 5 Apr 2007, Heikki Linnakangas wrote:
The purpose of the bgwriter_all_* settings is to shorten the duration of
the eventual checkpoint. The reason to shorten the checkpoint duration
is to limit the damage to other I/O activity it causes. My thinking is
that assuming the LDC patch is ef
I wrote:
> stark <[EMAIL PROTECTED]> writes:
>> [ packed varlena patch ]
> Applied with revisions.
Forgot to mention: one of the revisions was to not add the "sizes.sql"
test, because the output was platform-dependent and is likely to get
more so if any ability to change the toast thresholds gets
stark <[EMAIL PROTECTED]> writes:
> [ packed varlena patch ]
Applied with revisions. Waiting to see how badly the buildfarm
complains ;-) ... but I did test on little- and big-endian machines
with different MAXALIGN values.
regards, tom lane
---(e
Hi,
I agree to put the patch to core and the others (pg_compresslog and
pg_decompresslog) to contrib/lesslog.
I will make separate materials to go to core and contrib.
As for patches, we have tested against pgbench, DBT-2 and our
propriatery benchmarks and it looked to run correctly.
Regar
Hello, long time no see.
I'm sorry to interrupt your discussion. I'm afraid the code is getting
more complicated to continue to use fsync(). Though I don't intend to
say the current approach is wrong, could anyone evaluate O_SYNC
approach again that commercial databases use and tell me if and why
> > Tatsuo, would you please comment on this patch?
>
> Sure. I will come up with a comment by the end of this week.
The patches look good to me.
BTW, is anybody working on enabling the fill factor to the tables used
by pgbench? 8.3 will introduce HOT, and I think adding the feature
will make it
> > Tatsuo, would you please comment on this patch too?
>
> No problem. I will come up with a comment by the end of this week.
Here are comments.
1) latency log file format extention looks usefull (-x option).
2) it seems the "cleanup feature" (-X option) was withdrawed by the
author, but th
transaction_guarantee.v11.patch
- keep current, cleanup, more comments and docs
Brief Performance Analysis
--
I've tested 3 scenarios:
1. normal
2. wal_writer_delay = 100ms
3. wal_writer_delay = 100ms and transaction_guarantee = off
On my laptop, with a scale=1 pgbench d
Another problem seems to be that I'm not checking anywhere that a
regular connection (not autovac) is not using an autovac-reserved PGPROC
slot :-( I think I should tweak the logic that deals with
ReservedBackends but it doesn't look entirely trivial.
--
Alvaro Herrera
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The number of buffers evicted by normal backends in a bgwriter_delay
period is simple to keep track of, just increase a counter in
StrategyGetBuffer and reset it when bgwriter wakes up. We can use that
as an estimate of X with some
Simon Riggs wrote:
On Thu, 2007-04-05 at 17:14 +0100, Heikki Linnakangas wrote:
We could just review and apply ITAGAKI's patch as it is instead of
this snippet of it, but because that can take some time I'd like to
see this applied before that.
I think we are just beginning to understand the
On Thu, 2007-04-05 at 17:14 +0100, Heikki Linnakangas wrote:
> We could just review and apply ITAGAKI's patch as it is instead of
> this snippet of it, but because that can take some time I'd like to
> see this applied before that.
I think we are just beginning to understand the quality of Itaga
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I think the failure handling is correct in the "to-do list" approach,
> when an entry is read from the list, it's checked that the entry hasn't
> been removed from the hash table. Actually there was a bug in the
> original LDC patch in the failure
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
But I dislike copying the table entries anyway, see comment on -hackers.
Frankly the cycle id idea sounds more ugly and fragile to me. You'll
need to do multiple scans of the hash table that way, starting from top
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> But I dislike copying the table entries anyway, see comment on -hackers.
> Frankly the cycle id idea sounds more ugly and fragile to me. You'll
> need to do multiple scans of the hash table that way, starting from top
> every ti
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Here's a fix for the problem that on a busy system, mdsync never
finishes. See the original problem description on hackers:
This leaks memory, no? (list_delete_cell only deletes the ListCell.)
Oh, I just spotted another problem
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The number of buffers evicted by normal backends in a bgwriter_delay
> period is simple to keep track of, just increase a counter in
> StrategyGetBuffer and reset it when bgwriter wakes up. We can use that
> as an estimate of X with some safety ma
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I wonder if it wouldn't be better to clean this up by creating a
> separate typedef for segment numbers, with its own special values?
Probably. I remember having thought about it when I put in the
FORGET_DATABASE_FSYNC hack. I think I didn't do it bec
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's a fix for the problem that on a busy system, mdsync never
> finishes. See the original problem description on hackers:
This leaks memory, no? (list_delete_cell only deletes the ListCell.)
But I dislike copying the table entries anyway, see
Heikki Linnakangas wrote:
Here's a fix for the problem that on a busy system, mdsync never
finishes. See the original problem description on hackers:
http://archives.postgresql.org/pgsql-hackers/2007-04/msg00259.php
The solution is taken from ITAGAKI Takahiro's Load Distributed
Checkpoint patc
Greg Smith wrote:
On Thu, 5 Apr 2007, Heikki Linnakangas wrote:
Bgwriter has two goals:
1. keep enough buffers clean that normal backends never need to do a
write
2. smooth checkpoints by writing buffers ahead of time
Load distributed checkpoints will do 2. in a much better way than the
bgwr
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Uh, shouldn't CREATE TABLE LIKE INCLUDING CONSTRAINTS already be including
> > any indexes in the parent table?
>
> You could argue it should for unique indexes since our unique indexes are how
> we implement unique constrai
On Thu, 5 Apr 2007, Heikki Linnakangas wrote:
Bgwriter has two goals:
1. keep enough buffers clean that normal backends never need to do a write
2. smooth checkpoints by writing buffers ahead of time
Load distributed checkpoints will do 2. in a much better way than the
bgwriter_all_* guc option
While skimming over this I was baffled a bit about the usage of
(InvalidBlockNumber - 1) as value for FORGET_DATABASE_FSYNC. It took me
a while to realize that this code is abusing the BlockNumber typedef to
pass around *segment* numbers, so the useful range is much smaller and
thus the usage of t
On Thu, 5 Apr 2007, Heikki Linnakangas wrote:
Unfortunately because of the recent instrumentation and CheckpointStartLock
patches this patch doesn't apply cleanly to CVS HEAD anymore. Could you fix
the bitrot and send an updated patch, please?
The "Logging checkpoints and other slowdown cause
ITAGAKI Takahiro wrote:
Here is the latest version of Load distributed checkpoint patch.
Bgwriter has two goals:
1. keep enough buffers clean that normal backends never need to do a write
2. smooth checkpoints by writing buffers ahead of time
Load distributed checkpoints will do 2. in a much b
Bruce Momjian wrote:
I have applied the following patch which adds documentation and an
improved error message for an installation that does not use
--with-libxml.
and you broke the buildfarm ... you need to fix the regression test.
cheers
andrew
---(end of broadc
Here's a fix for the problem that on a busy system, mdsync never
finishes. See the original problem description on hackers:
http://archives.postgresql.org/pgsql-hackers/2007-04/msg00259.php
The solution is taken from ITAGAKI Takahiro's Load Distributed
Checkpoint patch. At the beginning of mdsy
ITAGAKI Takahiro wrote:
Here is the latest version of Load distributed checkpoint patch.
Unfortunately because of the recent instrumentation and
CheckpointStartLock patches this patch doesn't apply cleanly to CVS HEAD
anymore. Could you fix the bitrot and send an updated patch, please?
--
On Tue, 2007-04-03 at 19:45 +0900, Koichi Suzuki wrote:
> Bruce Momjian wrote:
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
>
> Thank you very much for including. Attached is an update of the patch
> acco
32 matches
Mail list logo
