On Tue, Feb 16, 2016 at 7:10 AM, Tom Lane wrote:
> Given this, I'm on board with just removing the weasel-wording about
> timer resolution, except maybe for commit_delay where useful values
> are small enough that it's a hazard on old systems.
+1, but I'd move the guidance for commit_delay's effe
On Tue, Feb 16, 2016 at 12:06 AM, Robert Haas wrote:
> On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund wrote:
>> Hi,
>>
>> Several places in our docs have blurbs like
>>> Note that on many systems, the effective resolution of sleep delays is
>>> 10 milliseconds; setting wal_writer_delay to a value
Robert Haas writes:
> On Tue, Feb 16, 2016 at 3:50 AM, Andres Freund wrote:
>> To back up my claim on this, read man 7 time
>> (e.g. http://linux.die.net/man/7/time), especially "The software clock,
>> HZ, and jiffies" and "High-resolution timers". To quote the most salient
>> point:
> Interesti
On Tue, Feb 16, 2016 at 3:50 AM, Andres Freund wrote:
> On 2016-02-16 09:13:09 +0100, Andres Freund wrote:
>> What we do we think the resolution is on modern
>> >systems? I would not have guessed that to be inaccurate.
>>
>> Depends in a lot of factors. The biggest being how busy you're system
>>
On 2016-02-16 09:13:09 +0100, Andres Freund wrote:
> What we do we think the resolution is on modern
> >systems? I would not have guessed that to be inaccurate.
>
> Depends in a lot of factors. The biggest being how busy you're system
> is. On an mostly idle system (i.e. workout so CPUs being
> o
On February 16, 2016 9:06:57 AM GMT+01:00, Robert Haas
wrote:
>On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund
>wrote:
>> Hi,
>>
>> Several places in our docs have blurbs like
>>> Note that on many systems, the effective resolution of sleep delays
>is
>>> 10 milliseconds; setting wal_writer_delay
On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund wrote:
> Hi,
>
> Several places in our docs have blurbs like
>> Note that on many systems, the effective resolution of sleep delays is
>> 10 milliseconds; setting wal_writer_delay to a value that
>> is not a multiple of 10 might have the same results
On February 16, 2016 3:09:16 AM GMT+01:00, Merlin Moncure
>I guess we should probably explain what is actually happening, namely
>that the precise sleep duration is delegated to the operating system
>scheduler which may cause the process to sleep longer than requested.
In not really seeing why: T
On Wed, Feb 10, 2016 at 4:15 PM, Andres Freund wrote:
> Hi,
>
> Several places in our docs have blurbs like
>> Note that on many systems, the effective resolution of sleep delays is
>> 10 milliseconds; setting wal_writer_delay to a value that
>> is not a multiple of 10 might have the same results
On Mon, Feb 15, 2016 at 11:23 AM, Peter Geoghegan wrote:
> commit_delay doesn't have any guidance like this, where it could
> certainly matter, because optimal settings are rarely greater than 10
> milliseconds.
Actually, it does, but it's in "29.4. WAL Configuration", not next to
the documentati
On Wed, Feb 10, 2016 at 2:15 PM, Andres Freund wrote:
> Afaik that's not the case on any recent operating system/hardware. So
> perhaps we should just remove all of those blurbs, or just replace them
> with something like "on some older systems the effective resolution of
> sleep delays is limited
Hi,
Several places in our docs have blurbs like
> Note that on many systems, the effective resolution of sleep delays is
> 10 milliseconds; setting wal_writer_delay to a value that
> is not a multiple of 10 might have the same results as setting it to
> the next higher multiple of 10.
Afaik that's
12 matches
Mail list logo
