Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: simplify register_dirty_segment()


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
  • Cc: pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: simplify register_dirty_segment()
  • Date: Mon, 25 Apr 2005 04:43:16 -0400
  • Message-id: <16658(dot)1114418596(at)sss(dot)pgh(dot)pa(dot)us>

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> That is, we don't care if a segment is dirty or not, if someone opened it,
> then we will fsync it at checkpoint time.

On platforms that I'm familiar with, an fsync call causes the kernel
to spend a significant amount of time groveling through its buffers
to see if any are dirty.  We shouldn't incur that cost to buy marginal
speedups at the application level.  (In other words, "it's only an
open/close" is wrong.)

Also, it's not clear to me how this idea works at all, if a backend holds
a relation open across more than one checkpoint.  What will re-register
the segment for the next cycle?

			regards, tom lane



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group