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

Re: Spread checkpoint sync

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spread checkpoint sync
Date: 2011-01-31 16:29:56
Message-ID: 17863.1296491396@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> IMHO we should re-consider the patch to sort the writes. Not so much 
> because of the performance gain that gives, but because we can then 
> re-arrange the fsyncs so that you write one file, then fsync it, then 
> write the next file and so on.

Isn't that going to make performance worse not better?  Generally you
want to give the kernel as much scheduling flexibility as possible,
which you do by issuing the write as far before the fsync as you can.
An arrangement like the above removes all cross-file scheduling freedom.
For example, if two files are on different spindles, you've just
guaranteed that no I/O overlap is possible.

> That way we the time taken by the fsyncs 
> is distributed between the writes,

That sounds like you have an entirely wrong mental model of where the
cost comes from.  Those times are not independent.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-01-31 16:31:13
Subject: Re: Allowing multiple concurrent base backups
Previous:From: Heikki LinnakangasDate: 2011-01-31 16:29:05
Subject: Re: Allowing multiple concurrent base backups

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group