Re: [HACKERS] TODO item

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: [HACKERS] TODO item
Дата
Msg-id 20000206230412X.t-ishii@sra.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] TODO item  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [HACKERS] TODO item  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: libpq API tweaks
Следующее
От: Sevo Stille
Дата:
Сообщение: Re: [HACKERS] Proposal for new SET variables for optimizercosts