From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing |
Date: | 2015-09-09 18:56:15 |
Message-ID: | alpine.DEB.2.10.1509092005380.21932@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>> (3) posix_fadvise on Linux is a bad idea... the good news is that it
>>> is not needed there:-) How good or bad an idea it is on other system
>>> is an open question...
>>
>> I don't know what is the best way to verify that, if some body else has
>> access to such a m/c, please help to get that verified.
>
> Why wouldn't we just leave it out then? Putting it in when the one
> platform we've tried it on shows a regression makes no sense. We
> shouldn't include it and then remove it if someone can prove it's bad;
> we should only include it in the first place if we have good benchmarks
> showing that it is good.
>
> Does anyone have a big Windows box they can try this on?
Just a box with a disk would be enough, it does not need to be big!
As I wrote before, FreeBSD would be a good candidate because the
posix_fadvise seems much more reasonable than on Linux, and should be
profitable, so it would be a pity to remove it.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-09 19:00:10 | Latent cache flush hazard in RelationInitIndexAccessInfo |
Previous Message | Oskari Saarenmaa | 2015-09-09 17:03:58 | Re: jsonb_concat: make sure we always return a non-scalar value |