| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2011-01-31 16:31:13 | Re: Allowing multiple concurrent base backups |
| Previous Message | Heikki Linnakangas | 2011-01-31 16:29:05 | Re: Allowing multiple concurrent base backups |