Tom Lane wrote:

Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends.

If the background writer starts using fsync(), we can have normal
backends that do a write() set a shared memory boolean.  We can then
test that boolean and do sync() only if other backends had to do their
own writes.

That seems like the worst of both worlds --- you still are depending on sync() for correctness.

Also, as long as backends only *seldom* do writes, making them fsync a
write when they do make one will be less of an impact on overall system
performance than having a sync() ensue shortly afterwards.  I think you
are focusing too narrowly on the idea that backends shouldn't ever wait
for writes, and failing to see the bigger picture.  What we need to
optimize is overall system performance, not an arbitrary restriction
that certain processes never wait for certain things.

Removing sync() entirely requires very accurate fsync()'ing in the background writer, the checkpointer and the backends. Basically none of them can mark a block "clean" if he fails to fsync() the relation later! This will be a mess to code.


# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== [EMAIL PROTECTED] #

---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Reply via email to