Re: [HACKERS] TODO item - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [HACKERS] TODO item
Date
Msg-id 20000206230412X.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: [HACKERS] TODO item  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] TODO item
List pgsql-hackers
> > BTW, I have worked a little bit on this item. The idea is pretty
> > simple. Instead of doing a real fsync() in pg_fsync(), just marking it
> > so that we remember to do fsync() at the commit time. Following
> > patches illustrate the idea. An experience shows that it dramatically
> > boosts the performance of copy. Unfortunately I see virtually no
> > difference for TPC-B like small many concurrent transactions. Maybe we
> > would need WAL for this. Comments?
> 
> 
> Can you be more specific.  How does fsync work now vs. your proposed
> change.  I did not see that here.  Sorry.

As already pointed out by many people, current buffer manager is not
very smart on flushing out dirty pages. From TODO.detail/fsync:

>This is the problem of buffer manager, known for very long time:
>when copy eats all buffers, manager begins write/fsync each
>durty buffer to free buffer for new data. All updated relations
>should be fsynced _once_ @ transaction commit. You would get
>the same results without -F...

With my changes, pg_fsync would just mark the relation (actually its
file descriptor) as it is needed fsync, instead of calling real fsync. 
Upon transaction commit, the mark would be checked and relations are
fsynced if necessary.

BTW, Hiroshi has raised a question with my changes, and I have written
to him (in Japanese, of course:-) to make sure that what I'm missing
here. I will let you know the result later.
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: libpq API tweaks
Next
From: Sevo Stille
Date:
Subject: Re: [HACKERS] Proposal for new SET variables for optimizercosts