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: 2005-04-25 08:43:16
Message-ID: 16658.1114418596@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2005-04-25 08:57:47 Re: Bad n_distinct estimation; hacks suggested?
Previous Message Qingqing Zhou 2005-04-25 08:13:39 simplify register_dirty_segment()