On Thu, Jan 10, 2019 at 8:42 PM, Robert Hass wrote:
Thanks for comments.
>or at least not nearly as useful the results of a sampling approach.
I agree with your opinion.
Because it can't be asserted that the wait event is a bottleneck just because
the number of wait event is large.
The same
On Wed, Nov 21, 2018 at 9:27 PM, Bruce Momjian wrote:
Hi, thank you for the information.
I understood that sampling is effective for investigation of waiting events.
By the way, you can see the number of wait events with "LWLOCK_STATS", right?
Is this function implemented because it is
On Sun, Oct 28, 2018 at 6:39 PM, legrand legrand wrote:
Hi, Thanks for comments.
I had overlooked the reply from you.
>You are right, sampling has to be "tuned" regarding the event(s) you want to
>catch.
I see. For tuning, you need to know the length of processing you want to
sample?
> May
On Mon, Nov 5, 2018 at 4:26 PM, Naoki Yotsunaga wrote:
>>2) it consumes system resources
>While the system is running, you are always sampling system information, do
>not you? Like Oracle ASH.
I don’t understand well how sampling is used.
In which scene do you use the sampling? Or is it both
On Sat, Nov 3, 2018 at 1:28 AM, Phil Florent wrote:
>2) it consumes system resources
While the system is running, you are always sampling system information, do not
you? Like Oracle ASH.
If so, does sampling have no significant impact on performance? Even if the
interval is 0.01 s or more.
On Mon, Oct 29, 2018 at 1:52 AM, Phil Florent wrote:
Hi, thank you for comments.
>Yes you will be able to solve bottlenecks with sampling. In interactive mode,
>a 1s interval is probably too large. I use 0s1 - 0s01 with my tool and it is
>normally OK.
With the tool you are using, can you
On Thu, Oct 4, 2018 at 8:22 PM, Yotsunaga Naoki wrote:
Hi, I understood and thought of your statistic comment once again. In the case
of sampling, is there enough statistic to investigate?
In the case of a long SQL, I think that it is possible to obtain a sufficient
sampling number.
However
On Thu, Oct 4, 2018 at 0:54 AM, Phil Florent wrote:
Phil, Michael, I appreciate your polite comments.
I understand as follows.
We can find it if we shorten the sampling interval, but a lot of information
comes out.
# The balance is important.
Also, it is not good unless we have enough samples.
On Thu, July 26, 2018 at 1:25 AM, Michael Paquier wrote:
> Even if you have spiky workloads, sampling may miss those, but even with
> adding counters for each event
> you would need to query the table holding the counters at an insane frequency
> to be able to perhaps get
> something out of it
-Original Message-
From: Yotsunaga, Naoki [mailto:yotsunaga.na...@jp.fujitsu.com]
Sent: Tuesday, June 26, 2018 10:18 AM
To: Postgres hackers
Subject: automatic restore point
>Hi, I attached a patch to output the LSN before execution to the server log
>>when executing a specifi
-Original Message-
From: Yotsunaga, Naoki [mailto:yotsunaga.na...@jp.fujitsu.com]
Sent: Tuesday, June 26, 2018 10:18 AM
To: Postgres hackers
Subject: automatic restore point
Hi, I attached a patch to output the LSN before execution to the server log
when executing a specific command
>-Original Message-
>From: Michael Paquier [mailto:mich...@paquier.xyz]
>Sent: Wednesday, July 11, 2018 3:34 PM
>Well, if you put in place correct measures from the start you would not have
>problems.
>It seems to me that there is no point in implementing something which is a
>-Original Message-
>From: Yotsunaga, Naoki [mailto:yotsunaga.na...@jp.fujitsu.com]
>Sent: Friday, July 6, 2018 5:05 PM
>Does that mean that the application (user) is interested in which table?
>For example, there are two tables A. It is ok even if one t
>-Original Message-
>From: Jaime Casanova [mailto:jaime.casan...@2ndquadrant.com]
>Sent: Tuesday, July 3, 2018 11:06 AM
>Thinking on Michael's suggestion of using event triggers, you can create an
>event >trigger to run pg_create_restore_point() on DROP, here's a simple
>example of how
>-Original Message-
>From: Michael Paquier [mailto:mich...@paquier.xyz]
>Sent: Tuesday, July 3, 2018 10:22 AM
>This kind of thing is heavily application-dependent. For example, you would
>likely not care if an operator, who has newly-joined the team in >charge of
>the maintenance of
uesday, June 26, 2018 2:31 PM
To: Yotsunaga, Naoki/四ツ永 直輝
Cc: Postgres hackers
Subject: Re: automatic restore point
On Tue, Jun 26, 2018 at 01:17:31AM +0000, Yotsunaga, Naoki wrote:
> The following is a description of "automatic restore point".
> 【Background】
> When DBA's ope
table.
-
Naoki Yotsunaga
-Original Message-
From: Michael Paquier [mailto:mich...@paquier.xyz]
Sent: Tuesday, June 26, 2018 2:16 PM
To: Isaac Morland
Cc: David G. Johnston ; Yotsunaga, Naoki/四ツ永 直輝
; Postgres hackers
Subject: Re: automatic restore point
On Mon, Jun 25, 2018 at
Hi, I'm a newbie to the hackers but I'd like to propose the "automatic restore
point" feature.
This feature automatically create backup label just before making a huge change
to DB. It's useful when this change is accidental case.
The following is a description of "automatic restore point".
18 matches
Mail list logo
