lative Statistics System proposed by this patch.
--
regards, Andrei Zubkov
Postgres Professional
specific workload views seems optimal choice to me.
Regards,
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hello!
On Thu, 27/06/2024 at 10:39 +0900, Masahiko Sawada:
> On Fri, May 31, 2024 at 4:19 AM Andrei Zubkov
> wrote:
> > As the vacuum process is a backend it has a workload
> > instrumentation.
> > We have all the basic counters available such as a number of blocks
&
r-relation basis. I mean individual cumulative counters for every
table and every index in the database.
Such counters will provide us a clear view about vacuum workload on
individual objects of the database, providing means to measure the
efficiency of performed vacuum fine tuning.
--
Andrei
o some
kind of obvious error here? Couple examples follows:
SELECT 0/0;
- or -
DO $$
BEGIN
RAISE 'test error';
END;
$$ LANGUAGE plpgsql;
My personal choice would be the last one.
--
regards, Andrei Zubkov
Postgres Professional
t
> messages.
I've noted a strange space in a commit message of 0001 patch:
"I t is needed for upcoming patch..."
It looks like a typo.
--
regards, Andrei Zubkov
Postgres Professional
A little fix in "level_tracking" tests after merge.
--
regards, Andrei Zubkov
Postgres Professional
From ed7531ba471061346922bbcb00d92738f6515a3f Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Fri, 17 Nov 2023 11:27:20 +0300
Subject: [PATCH 1/2] pg_stat_statements tests: Ad
Hi hackers,
Patch rebased to the current master
--
regards, Andrei Zubkov
Postgres Professional
From ff2ff96352a843d32a1213a1e953503fd1525b7b Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Fri, 17 Nov 2023 00:27:24 +0300
Subject: [PATCH 1/2] pg_stat_statements tests: Add NOT NULL checking
reset can be used for that
purpose.
--
regards, Andrei Zubkov
Postgres Professional
mp if it exists."
There are four such places actually - every time when the
SINGLE_ENTRY_RESET macro is used. The logic of reset performed is
described a bit in this macro definition. It seems quite redundant to
repeat this description four times. But I've noted that "remove" terms
says rebase
needed since 2023-08-21.
regards, Andrei Zubkov
nsactions providing
resource consumption information besides timing statistics.
regards, Andrei Zubkov
Postgres Professional
e a min/max reset between samples. And if such reset was performed
at least we know when it was performed.
regards,
Andrei Zubkov
Postgres Professional
Hi,
During last moving to the current commitfest this patch have lost its
reviewers list. With respect to reviewers contribution in this patch, I
think reviewers list should be fixed.
regards,
Andrei Zubkov
Postgres Professional
The Russian Postgres Company
Hi hackers,
New version 23 attached. It contains rebase to the current master.
Noted that v1.11 adds new fields to the pg_stat_sstatements view, but
leaves the PGSS_FILE_HEADER constant unchanged. It this correct?
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian
l 4 fields for which minmax_stats_since displays the time.
Agreed.
New version is attached.
regards, Andrei
From 187aeb26df54daea4f38eb9a8605ee09985b55ae Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Wed, 22 Mar 2023 10:09:58 +0300
Subject: [PATCH 1/2] pg_stat_statements tests: Add NOT NULL c
A little comment fix in update script of a patch
--
Andrei Zubkov
From 52e75fa05f5dea5700d96aea81ea81d91492b018 Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Thu, 16 Mar 2023 13:18:59 +0300
Subject: [PATCH 1/2] pg_stat_statements tests: Add NOT NULL checking of
pg_stat_statements_reset
estamp rather than void, but IS NOT NULL applied on
> the
> existing queries would also return true. This would clean up quite a
> few diffs in the main patch..
Splitting this commit seems reasonable to me.
New version is attached.
From 52e75fa05f5dea5700d96aea81ea81d91492b018 Mon Sep 17 00:00:
Hi,
I've done a rebase of a patch to the current master.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From e43e9eab39bbd377665a7cad3b7fe7162f8f6578 Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Sat, 11 Mar 2023 09:53:10 +0300
Su
omething strange in new test files - I've
mentioned this in a thread of a patch. Once there will be any solution
I'll do a rebase again as soon as possible.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| t
Those statements is not related to any WAL tests. It seems a little bit
incorrect to me.
Are we need some changes here?
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ither not set up right
> or is exposing a bug?
Thank you, I've missed it.
>
> Please check if this is a real failure or a cfbot failure.
>
It is my failure. Just forgot to update meson.build
I think CFBot should be happy now.
Regards,
--
Andrei Zubkov
From 0d97c3d3bc0f00c3a1c2b
Hi!
I've attached a new version of a patch - rebase to the current master.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From 92816cfb26f0ebd35c00a6ce4f25e45f08d83790 Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Wed, 1 Mar 2023 11:
Hi,
The final version of this patch should fix meson build and tests.
--
Andrei Zubkov
From 94784bccd48a83cba58d6017253d0b8f051e159c Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Thu, 26 Jan 2023 13:18:11 +0300
Subject: [PATCH] pg_stat_statements: Track statement entry timestamp
This
ect resets, perfermed by someone
else.
Regards
--
Andrei Zubkov
From 8214db3676e686993bcf73963f78c96baeb04c4e Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Wed, 25 Jan 2023 18:13:14 +0300
Subject: [PATCH] pg_stat_statements: Track statement entry timestamp
This patch adds stats_since an
3) I don't understand why the patch is adding "IS NOT NULL AS t" to
> various places in the regression tests.
The most of tests was copied from the previous version. I'll recheck
them.
>
> 4) I rather dislike the "minmax" naming, because that's often used in
> other contexts (for BRIN indexes), and as I mentioned maybe it should
> also cover the "mean" fields.
Agreed, but I couldn't make it better. Other versions seemed worse to
me...
>
>
Regards, Andrei Zubkov
Hi,
I've rebased this patch so that it can be applied after 57d6aea00fc.
v14 attached
--
regards, Andrei
From 6c541f3001d952e72e5d865fde09de3fb4f36d10 Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Fri, 8 Apr 2022 23:12:55 +0300
Subject: [PATCH] pg_stat_statements: Track statement
ith keeping minmax_only, stats_reset and
> num_remove as is.
Using an entry as a macro parameter looks good, I'm fine with "e".
> Apart from that I think this is ready!
v13 attached
--
regards, Andrei
From b6b1eab21f5b873ec9a1bb13b82cca7d6bcaab32 Mon Sep 17 00:00:00 2001
Fro
Julien,
On Sun, 2022-04-03 at 17:56 +0800, Julien Rouhaud wrote:
> Just another minor nitpicking after a quick look:
>
> + This field will be zero if ...
> [...]
> + this field will contain zero until this statement ...
>
> The wording should be consistent, so either "will be zero" or "will
> co
f('pg_stat_statements_reset'::regproc);
>
> I don't think this bring any useful coverage.
It is a little bit unclear to me what is the best solution here.
--
regards, Andrei
From 9359b7dfdadeb7a672c146030995626150acf231 Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date
Hi Julien,
On Sun, 2022-04-03 at 15:07 +0800, Julien Rouhaud wrote:
> +static TimestampTz
> +entry_reset(Oid userid, Oid dbid, uint64 queryid, bool minmax_only)
> {
> HASH_SEQ_STATUS hash_seq;
> pgssEntry *entry;
> + Counters *entry_counters;
>
> Do we really need an extra variable?
I've forgot to set collation here.
v11 attached
--
regards, Andrei
From c5900f1c689b2a74edbc30b66c9a73e25b85484a Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Sun, 3 Apr 2022 07:28:59 +0300
Subject: [PATCH] pg_stat_statements: Track statement entry timestamp
This patch adds stats_since column to the pg_sta
On Sat, 2022-04-02 at 14:11 +0300, Andrei Zubkov wrote:
> On Sat, 2022-04-02 at 18:56 +0800, Julien Rouhaud wrote:
> > Maybe a macro would be better here? I don't know if that's
> > generally
> > ok or
> > just old and not-that-great code, but there are o
On Sat, 2022-04-02 at 18:56 +0800, Julien Rouhaud wrote:
> Maybe a macro would be better here? I don't know if that's generally
> ok or
> just old and not-that-great code, but there are other places relying
> on macros
> when a plain function call isn't that convenient (like here returning
> 0 or
tat_statements_reset function result caused a
confiderable tests update. Also, I'm not sure that my description of
this feature in the docs is blameless..
After all, I'm a little bit in doubt about this feature, so I'm ready
to rollback it.
v9 attached
--
regards, Andrei
From 78f3e
d by this solution or any other reset was
performed by someone else. It seems valuable to me, but it changes the
result type of the pg_stat_statements_reset() function, so I don't know
if we can do that right now.
v8 attached
--
regards, Andrei
From a905dcbd8ca891a1aaf9652324650b87cdcae001 Mo
e
> )
Of course!
>
> Doc:
>
> + stats_since timestamp with
> time zone
> +
> +
> + Timestamp of statistics gathering start for the statement
>
> The description is a bit weird. Maybe like "Time at which statistics
> gathering
&g
e planning statistics
is zero in case of disabled tracking. I think sampling solution could
easily handle this.
--
Regards, Andrei Zubkov
From 68cd5efee7b3dbdb1b4034ab4c47249a23ca9d04 Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Fri, 25 Mar 2022 12:30:03 +0300
Subject: [PATCH] pg_stat_statem
think about a
little bit different statio view for that? For example, a plain view
for all tables (regular and TOASTs)...
--
Regards, Andrei Zubkov
ong here. My opinion
is to use NULLs, as they seems more suitable here. But this can be done
only if we are not expecting significant side effects.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
NULLs before and
backward compatibility seems broken. Another approach is to return the
old values of min/max stats and the old aux_stats_since value until the
next statement execution but it seems strange when the reset was
performed and it doesn't affected any stats instantly.
regards,
An
ats_since" field holds the timestamp of hashtable entry, but not the
reset time. The same applies to aux_stats_since - for new statement it
holds its entry time, but in case of reset it will hold the reset time.
"stats_reset" name seems a little bit
It seems we need to bump catalog version here.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, 2021-12-03 at 17:03 +0300, Andrei Zubkov wrote:
> I've added the following fields to the pg_stat_statements view:
>
> min_plan_time_local float8,
> max_plan_time_local float8,
> min_exec_time_local float8,
> max_exec_time_local float8
>
> a
since - it seems to be more self-explaining to me. But
I'm not sure in the current naming at all.
The tests is not ready yet, but any thoughts about the patch are
welcome right now.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From bea0ae
change in a view definition. Counting all
indexes regardless of states seems more reasonable to me.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
;, 't', 'm');
Reported by Sergey Grinko.
Regards.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From ffde04cf285de32c7b8521c0aa9d0b36c1e8b7f7 Mon Sep 17 00:00:00 2001
From: Andrei Zubkov
Date: Mon, 29 Nov 2021 16:33:34 +0300
with except of min and max
time values. It seems that partial reset is needed here resetting
min/max values during a sample. But overall min/max values will be lost
in this case. Does addition of resettable min/max metrics to the
pg_stat_statemets view seems reasonable here?
--
Andrei Zubkov
Pos
Hi, Anton!
I've corrected the patch and attached a new version.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, 2021-10-06 at 18:13 +0300, Мельников Антон Андреевич wrote:
> Hi, Andrey!
>
> I’ve tried to apply your pa
ight be qute difficult.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
/20201202040516.GA43757@nol
Version 2 of patch attached.
pg_stat_statements version is now 1.10 and patch is based on 0f61727.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From 321ce82f22894be39297515268c1f3bed74778e2 Mon Sep 17 00:00:00 2001
From
On Wed, 2021-04-14 at 17:32 +0800, Julien Rouhaud wrote:
>
> did you enable compute_query_id new parameter?
Hi, Julien!
Thank you very much! I've missed it.
>
ok now and
statements are not tracked at all.
Am I mistaken somewhere? Maybe you know why this is happening?
Thank you!
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, 2021-04-09 at 00:23 +, kuroda.hay...@fujitsu.com wrote:
> Dear And
On Wed, 2021-04-07 at 17:26 +0900, Seino Yuki wrote:
> Is it necessary to update the version of pg_stat_statements now that
> the
> release is targeted for PG15?
I think, yes, version of pg_stat_statements is need to be updated. Is
it will be 1.10 in PG15?
Regards,
--
Andrei Zubkov
Dear Kuroda,
> I don't like the idea because such a column has no meaning for the
> specific row.
> I prefer storing timestamp if GetCurrentTimestamp() is cheap.
I agree. New version attached.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres
specific statement.
> FTR that's how powa currently deals with reset/eviction.
PoWA sampling is much more frequent than pg_profile. For PoWA it is, of
cource, very unlikely scenario, but still possible.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
if (api_version >= PGSS_V1_9)
> > + {
> > + values[i++] = TimestampTzGetDatum(first_seen);
> > + }
>
> I think {} is not needed here.
Of course, thank you!
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
This is a proposal for a new feature in pg_stat_statements extension.
As a statistical extension providing counters pg_stat_statements
extension is a target for various sampling solutions. All of them
interested in calculation of statement statistics increments between
two samples. But we face a p
On Fri, 2021-03-19 at 22:15 +0800, Julien Rouhaud wrote:
> I disagree. The point of that field is to help users configuring
> pg_stat_statements.max, as evictions have a huge overhead in many
> workloads.
>
> If users remove entries for some reasons, we don't have to give the
> impression
> that
59 matches
Mail list logo
