On Fri, Jun 09, 2023 at 02:58:42PM +0900, Michael Paquier wrote:
> FWIW, I'm OK with the patch, without the need to worry about the
> performance. Even if that's the case, we could just mark all these as
> inline and move on..
I am attempting to get all that done for the beginning of the
Hi,
On 6/9/23 11:20 AM, Masahiro Ikeda wrote:
Hi,
On 2023-06-09 13:26, Drouvot, Bertrand wrote:
Hi,
On 6/9/23 1:15 AM, Michael Paquier wrote:
On Thu, Jun 08, 2023 at 10:57:55AM +0900, Masahiro Ikeda wrote:
(Excuse me for cutting in, and this is not directly related to the thread.)
+1. I'm
Hi,
On 2023-06-09 13:26, Drouvot, Bertrand wrote:
Hi,
On 6/9/23 1:15 AM, Michael Paquier wrote:
On Thu, Jun 08, 2023 at 10:57:55AM +0900, Masahiro Ikeda wrote:
(Excuse me for cutting in, and this is not directly related to the
thread.)
+1. I'm interested in the feature.
This is just a
On Fri, Jun 09, 2023 at 06:26:07AM +0200, Drouvot, Bertrand wrote:
> +1, that's something I've in mind to work on once/if this patch is/get
> committed.
FWIW, I'm OK with the patch, without the need to worry about the
performance. Even if that's the case, we could just mark all these as
inline
Hi,
On 6/9/23 1:15 AM, Michael Paquier wrote:
On Thu, Jun 08, 2023 at 10:57:55AM +0900, Masahiro Ikeda wrote:
(Excuse me for cutting in, and this is not directly related to the thread.)
+1. I'm interested in the feature.
This is just a example and it probable be useful for other users. IMO,
On Thu, Jun 08, 2023 at 10:57:55AM +0900, Masahiro Ikeda wrote:
> (Excuse me for cutting in, and this is not directly related to the thread.)
> +1. I'm interested in the feature.
>
> This is just a example and it probable be useful for other users. IMO, at
> least, it's better to improve the
Hi,
On 2023-05-19 16:48, Drouvot, Bertrand wrote:
While at it, I think that making use of an enum might also be an open
door
(need to think more about it) to allow extensions to set their own wait
event.
Something like RequestNamedLWLockTranche()/GetNamedLWLockTranche() are
doing.
Currently
Hi,
On 5/19/23 12:36 AM, Michael Paquier wrote:
On Thu, May 18, 2023 at 12:28:20PM -0400, Robert Haas wrote:
I mean, I agree that it would probably be hard to measure any real
performance difference. But I'm not sure that's a good reason to add
cycles to a path where we don't really need to.
On Thu, May 18, 2023 at 12:28:20PM -0400, Robert Haas wrote:
> I mean, I agree that it would probably be hard to measure any real
> performance difference. But I'm not sure that's a good reason to add
> cycles to a path where we don't really need to.
Honestly, I am not sure that it's worth
On Wed, May 17, 2023 at 7:38 PM Andres Freund wrote:
> On 2023-05-17 09:22:19 -0400, Robert Haas wrote:
> > Adding pgstat_get_wait_extension adds runtime cost for no corresponding
> > benefit. Having a special case in the code to avoid that seems worthwhile.
>
> I don't think that should ever be
On 2023-05-17 09:22:19 -0400, Robert Haas wrote:
> Adding pgstat_get_wait_extension adds runtime cost for no corresponding
> benefit. Having a special case in the code to avoid that seems worthwhile.
I don't think that should ever be used in a path where performance is
relevant?
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
On Wed, May 17, 2023 at 09:22:19AM -0400, Robert Haas wrote:
> It seems to me that your automatic generation code might need a
> special case for wait event types that contain only a single wait
> event. But that doesn't seem like a bad thing to have. Adding
> pgstat_get_wait_extension adds
On Tue, May 16, 2023 at 1:14 AM Michael Paquier wrote:
> These are the two things refactored in the patch, explaining the what.
> The reason behind the why is to make the script in charge of
> generating all these structures and functions consistent for all the
> wait event classes, simply.
Hi,
On 5/16/23 8:16 AM, Michael Paquier wrote:
On Mon, May 15, 2023 at 10:07:04AM +0200, Drouvot, Bertrand wrote:
This is preliminary work to autogenerate some wait events
code and documentation done in [1].
The patch introduces 2 new "wait events" (WAIT_EVENT_EXTENSION
and
On Mon, May 15, 2023 at 10:07:04AM +0200, Drouvot, Bertrand wrote:
> This is preliminary work to autogenerate some wait events
> code and documentation done in [1].
>
> The patch introduces 2 new "wait events" (WAIT_EVENT_EXTENSION
> and WAIT_EVENT_BUFFER_PIN) and their associated functions
>
Hi,
On 5/16/23 7:14 AM, Michael Paquier wrote:
On Mon, May 15, 2023 at 06:01:02PM -0700, Andres Freund wrote:
On 2023-05-16 09:38:54 +0900, Michael Paquier wrote:
On Mon, May 15, 2023 at 05:17:16PM -0700, Andres Freund wrote:
These are the two things refactored in the patch, explaining the
On Tue, May 16, 2023 at 1:14 AM Michael Paquier wrote:
> On Mon, May 15, 2023 at 06:01:02PM -0700, Andres Freund wrote:
> > Why those tweaks are necessary is precisely what I am asking for.
>
> Then the perl script generates the same structures for all the wait
> event classes, with all the
On Mon, May 15, 2023 at 06:01:02PM -0700, Andres Freund wrote:
> On 2023-05-16 09:38:54 +0900, Michael Paquier wrote:
>> On Mon, May 15, 2023 at 05:17:16PM -0700, Andres Freund wrote:
>>> IMO the submission should include why automating requires these changes
>>> (yours
>>> doesn't really
Hi,
On 2023-05-16 09:38:54 +0900, Michael Paquier wrote:
> On Mon, May 15, 2023 at 05:17:16PM -0700, Andres Freund wrote:
> > IMO the submission should include why automating requires these changes
> > (yours
> > doesn't really either). I can probably figure it out if I stare a bit at the
> >
On Mon, May 15, 2023 at 05:17:16PM -0700, Andres Freund wrote:
> IMO the submission should include why automating requires these changes (yours
> doesn't really either). I can probably figure it out if I stare a bit at the
> code and read the other thread - but I shouldn't need to.
Hm? My
Hi,
On 2023-05-16 07:30:54 +0900, Michael Paquier wrote:
> On Mon, May 15, 2023 at 11:29:56AM -0700, Andres Freund wrote:
> > Without an explanation for why this change is needed for [1], it's hard to
> > give useful feedback...
>
> The point is to integrate the wait event classes for buffer pin
On Mon, May 15, 2023 at 11:29:56AM -0700, Andres Freund wrote:
> Without an explanation for why this change is needed for [1], it's hard to
> give useful feedback...
The point is to integrate the wait event classes for buffer pin and
extension into the txt file that automates the creation of the
Hi,
On 2023-05-15 10:07:04 +0200, Drouvot, Bertrand wrote:
> Please find attached a patch to $SUBJECT.
>
> This is preliminary work to autogenerate some wait events
> code and documentation done in [1].
>
> The patch introduces 2 new "wait events" (WAIT_EVENT_EXTENSION
> and
Hi hackers,
Please find attached a patch to $SUBJECT.
This is preliminary work to autogenerate some wait events
code and documentation done in [1].
The patch introduces 2 new "wait events" (WAIT_EVENT_EXTENSION
and WAIT_EVENT_BUFFER_PIN) and their associated functions
25 matches
Mail list logo
