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 |
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 |