Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available

From: Jianghua Yang <yjhjstz(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available
Date: 2025-03-26 23:54:12
Message-ID: CAAZLFmQUq5PZq3ZjBiUHhm7_MzAry_c1AyFdNHATLSvn95+5QQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

It Makes sense, but we can distinguish such code which needs `
CLOCK_MONOTONIC`.

Now I add the configure option `--with-clock-monotonic-coarse`.

Michael Paquier <michael(at)paquier(dot)xyz> 于2025年3月26日周三 15:34写道:

> On Wed, Mar 26, 2025 at 11:14:47AM -0700, 杨江华 wrote:
> > This patch modifies the instr_time.h header to prefer
> CLOCK_MONOTONIC_COARSE
> > when available. By using CLOCK_MONOTONIC_COARSE, we can leverage a lower
> > resolution(4ms) but faster alternative for timing operations, which
> reduces
> > the overhead of frequent timestamp retrievals. This change is expected to
> > provide performance improvements, especially in scenarios with frequent
> > timing operations.
> >
> > *Key Changes:*
> >
> > • *CLOCK_MONOTONIC_COARSE* is used when available, offering faster
> > performance with slightly reduced precision.
> >
> > • For macOS, *CLOCK_MONOTONIC_RAW* remains the preferred choice due to
> its
> > higher resolution.
> >
> > • *CLOCK_MONOTONIC* is used as a fallback when neither of the above
> options
> > is available.
>
> -#if defined(__darwin__) && defined(CLOCK_MONOTONIC_RAW)
> +#ifdef CLOCK_MONOTONIC_COARSE
> +#define PG_INSTR_CLOCK CLOCK_MONOTONIC_COARSE
> +#elif defined(__darwin__) && defined(CLOCK_MONOTONIC_RAW)
>
> Why would we want to make this the default? CLOCK_MONOTONIC_COARSE
> could show benefits in some code paths. Now, it can also have a
> precision of a few milliseconds, and we have a bunch of code paths
> that rely on clock_gettime() to be more precise than that so it could
> lead to random decisions. You could make that configurable with a
> GUC, but it would mean plastering some decision-making in instr_time.h
> based on such a GUC, which would likely be annoying performance-wise.
>
> We are at the end of the v18 development cycle, so it is going to get
> some time before you get any review. Good to see that you are
> tracking this patch in the commit fest:
> https://commitfest.postgresql.org/patch/5669/
> --
> Michael
>

Attachment Content-Type Size
0001-Add-optional-support-for-CLOCK_MONOTONIC_COARSE-via-.patch application/octet-stream 3.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2025-03-27 00:48:21 Re: read stream on amcheck
Previous Message David Rowley 2025-03-26 23:09:35 Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET