| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | marcin mank <marcin(dot)mank(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after |
| Date: | 2010-02-15 11:19:24 |
| Message-ID: | 407d949e1002150319j47d4c26dn33c5ea74f03ca709@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Mon, Feb 15, 2010 at 10:02 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi Marcin,
>
> Sounds rather unlikely to me. Its likely handled at an upper layer (vfs in linux' case) and only overloaded when an optimized implementation is available.
> Which os do you see implementing that only on a part of the filesystems?
>
> A runtime check would be creating, fsyncing and deleting a directory for every directory youre fsyncing because they could be on a different fs...
We could just not check the result code of the fsync. Or print a
warning the first time and stop trying subsequently.
When do we cut the alpha? If I look at it at about 10-11pm EST is that too late?
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | marcin mank | 2010-02-15 11:34:44 | Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after |
| Previous Message | Andres Freund | 2010-02-15 10:02:50 | Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tim Bunce | 2010-02-15 11:32:57 | Re: CommitFest Status Summary - 2010-02-14 |
| Previous Message | Tim Bunce | 2010-02-15 10:51:14 | Re: PostgreSQL::PLPerl::Call - Simple interface for calling SQL functions from PostgreSQL PL/Perl |