On Fri, Jul 25, 2025 at 08:57:29AM +, Bertrand Drouvot wrote:
> This was not needed before fc415edf8ca8, and I think it was better to use
> pgstat_have_pending_wal() to not have to set a flag to every places
> pgWalUsage.XX
> changes.
At the end, this cost makes the separation of the code lay
Hi,
On Fri, Jul 25, 2025 at 10:38:59AM +0900, Michael Paquier wrote:
> On Thu, Jul 24, 2025 at 07:38:46AM +, Bertrand Drouvot wrote:
> > What about?
> >
> > - create a global variable but that should be used only by extensions? Say,
> > pgstat_report_custom_fixed
> >
> > - for builtin fixed-
On Thu, Jul 24, 2025 at 07:38:46AM +, Bertrand Drouvot wrote:
> On Thu, Jul 24, 2025 at 09:34:45AM +0900, Michael Paquier wrote:
>> These numbers mean that we have enough room for 7 more builtins kinds,
>
> 11 for builtins kinds? (from 13 to 23)
>
> 9 for custom kinds including experimental? (
Hi,
On Thu, Jul 24, 2025 at 09:34:45AM +0900, Michael Paquier wrote:
> On Wed, Jul 23, 2025 at 12:00:55PM -0400, Andres Freund wrote:
> > On 2025-07-23 09:54:12 +0900, Michael Paquier wrote:
> >> Noted. I was wondering originally if the threshold for the builtin
> >> and custom kinds should be lo
On Wed, Jul 23, 2025 at 12:00:55PM -0400, Andres Freund wrote:
> On 2025-07-23 09:54:12 +0900, Michael Paquier wrote:
>> Noted. I was wondering originally if the threshold for the builtin
>> and custom kinds should be lowered, as well. Perhaps that's just too
>> optimistic, so we can first lower
On Wed, Jul 23, 2025 at 11:59:11AM -0400, Andres Freund wrote:
> On 2025-07-23 10:23:53 +, Bertrand Drouvot wrote:
>> Indeed, with a single boolean flag, then how could a stat say that it has
>> nothing
>> pending anymore (when flushing) without saying "all the stats have nothing
>> pending" (
Hi,
On 2025-07-23 09:54:12 +0900, Michael Paquier wrote:
> On Tue, Jul 22, 2025 at 10:57:06AM -0400, Andres Freund wrote:
> > It seems rather unsurprising that that causes a slowdown.
> >
> > The pre-check is there to:
> > /* Don't expend a clock check if nothing to do */
> >
> > but you mad
Hi,
On 2025-07-23 10:23:53 +, Bertrand Drouvot wrote:
> On Wed, Jul 23, 2025 at 05:09:54PM +0900, Michael Paquier wrote:
> > so we don’t really need to mix multiple numbers; we could just have a single
> > boolean flag that any fixed-sized stats kinds can set to let the reporting
> > know
> >
On Wed, Jul 23, 2025 at 05:09:54PM +0900, Michael Paquier wrote:
> On Jul 23, 2025, at 16:33, Bertrand Drouvot
> wrote:
> > Maybe we could use a flag, say:
> >
> > #define PGSTAT_PENDING_IO (1 << 0)
> > #define PGSTAT_PENDING_WAL(1 << 1)
> > #define PGSTAT_PENDING_SLRU (1 << 2)
> >
>
On Jul 23, 2025, at 16:33, Bertrand Drouvot
wrote:
> Maybe we could use a flag, say:
>
> #define PGSTAT_PENDING_IO (1 << 0)
> #define PGSTAT_PENDING_WAL(1 << 1)
> #define PGSTAT_PENDING_SLRU (1 << 2)
>
> and check for a pgstat_pending_mask in pgstat_report_stat() instead?
>
> They wo
Hi,
On Wed, Jul 23, 2025 at 09:54:12AM +0900, Michael Paquier wrote:
> Then, about the loop used here, I'd be OK to keep the past shortcuts
> for the builtin fixed-sized stats kinds with the requirement that new
> builtin stats kinds need to hack into pgstat_report_stat() themselves
> on efficienc
On Tue, Jul 22, 2025 at 10:57:06AM -0400, Andres Freund wrote:
> It seems rather unsurprising that that causes a slowdown.
>
> The pre-check is there to:
> /* Don't expend a clock check if nothing to do */
>
> but you made it way more expensive than a clock check would have been (not
> coun
Hi,
I wanted to run some performance tests for [1] and looked at the profile of a
workload with a lot of short queries. And was rather surprised to see
pgstat_report_stat() to be the top entry - that certainly didn't use to be the
case.
For the, obviously rather extreme, workload of a pgbench ses
13 matches
Mail list logo
