From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN |
Date: | 2023-05-17 23:28:58 |
Message-ID: | ZGVjOujHAXEGXGVX@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 18, 2023 at 07:48:26AM +0900, Michael Paquier wrote:
> Okay. We are going to need an approach similar to what's done for
> src/backend/nodes where two things are generated in order to be able
> to have some of the wait event classes be treated as exceptions in the
> switch calling each function (pgstat_get_wait_event). I'd assume:
> - Create the code calling the functions automatically, say in a
> wait_event_type.switch.c or something like that. If a class has one
> single element, generate the code from it.
> - Create a second file with the functions and their internals, as the
> patch does now (like wait_event_type.funcs.c?), discarding classes
> with single elements.
> - Skip the creation of the enum structures for single-element classes,
> as well.
On top of that, why don't we just apply some inlining to all the
pgstat_get_wait_*() functions? If we do that, even the existing
functions could see a benefit on top of the ones associated to classes
with single elements. Inlining may not be always applied depending on
what the compiler wants, of course..
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-05-17 23:38:32 | Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN |
Previous Message | Jeff Davis | 2023-05-17 22:59:06 | Re: Order changes in PG16 since ICU introduction |