Hi,
I rebased the patch set on the master (7e5e1bba03), and the regression
test is good. Therefore, I changed the status of the patch: "needs review".
Happy New Year!
I rebased my patches on HEAD.
Please find attached files. :-D
Thanks,
Tatsuro Ya
patch on PG10, 11, 12, and 13.
I wonder the column names added by \dX+ is fine? For example,
"Ndistinct_size" and "Dependencies_size". It looks like long names,
but acceptable?
Regards,
Tatsuro Yamada
Hi,
On 2021/01/08 0:56, Tomas Vondra wrote:
On 1/7/21 3:47 PM, Alvaro Herrera wrote:
On 2021-Jan-07, Tomas Vondra wrote:
On 1/7/21 1:46 AM, Tatsuro Yamada wrote:
I overlooked the check for MCV in the logic building query
because I created the patch as a new feature on PG14.
I'm not
rfect. Thanks for your time on this.
Thanks for fixing the problem! :-D
Regards,
Tatsuro Yamada
r.
After reproducing it here, that *is* a coincidence. I shall now go beat
up on the correct blame-ee, instead.
I did "make installcheck-parallel" on 7bb97211a, just in case. It was
successful. :-D
Regards,
Tatsuro Yamada
x27;
END AS "Mcv",
COALESCE(pg_catalog.length(stxdndistinct), 0) AS "N_size",
COALESCE(pg_catalog.length(stxddependencies), 0) AS "D_size",
COALESCE(pg_catalog.length(stxdmcv), 0) AS "M_size"
FROM pg_catalog.pg_statistic_ext
FROM pg_catalog.pg_statistic_ext es
LEFT JOIN pg_catalog.pg_statistic_ext_data esd
ON es.oid = esd.stxoid
INNER JOIN pg_catalog.pg_class c
ON es.stxrelid = c.oid
ORDER BY 1, 2;
Regards,
Tatsuro Yama
ch.
Please fined the patch file. :-D
Regards,
Tatsuro Yamada
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 221a967bfe..fd860776af 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1918,6 +1918,20
Hi Tomas,
On 2020/10/29 4:07, Tomas Vondra wrote:
On Wed, Oct 28, 2020 at 04:20:25PM +0900, Tatsuro Yamada wrote:
Hi,
Results of \dX and \dX+:
postgres=# \dX
List of extended statistics
Schema | Name | Definition
Hi Tomas,
On 2020/10/29 4:06, Tomas Vondra wrote:
On Wed, Oct 28, 2020 at 03:07:56PM +0900, Tatsuro Yamada wrote:
Hi Michael-san and Hackers,
On 2020/09/30 15:19, Michael Paquier wrote:
On Thu, Sep 17, 2020 at 02:55:31PM +0900, Michael Paquier wrote:
Could you provide at least a rebased
=# \dX+
foo. pg_toast.stts_2 stts_hoge
information_schema. public. stts_3 yama.
pg_catalog. stts_1 stts_4
Regards,
Tatsuro Yamada
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql
parallel.
Attached patches is following:
- 0001-v8-Add-dX-command-on-psql.patch
- 0002-Add-regression-test-of-dX-to-stats_ext.sql.patch
However, I feel the test of \dX is not elegant, so I'm going to try
creating another one since it would be better to be aware of the context
of existing extended st
tats_ext.sql-another-ver
Both regression tests 0002 and 0003 are okay for me, I think.
Could you choose one?
Regards,
Tatsuro Yamada
From b22ebf34fc09e246f8d4cf408f76a6753f3d6bcb Mon Sep 17 00:00:00 2001
From: Tatsuro Yamada
Date: Tue, 10 Nov 2020 16:47:45 +0900
Subject: [PATCH] Add regression test of
ace column names
- 0002: Recreate regression test based on 0001
Regards,
Tatsuro Yamada
From 85fe05c3020cd595ae8d5c2cc6f695b39f4a6e03 Mon Sep 17 00:00:00 2001
From: Tatsuro Yamada
Date: Tue, 17 Nov 2020 13:30:57 +0900
Subject: [PATCH 2/2] Recreate regression test
---
src/test/regress/expect
ends. It may occur a shortage of memory and OOM killer.
We think the affected version are PG12 or later. I believe it would be
better to fix the problem. Any thoughts?
Regards,
Tatsuro Yamada
DROP TABLE IF EXISTS pr CASCADE;
DROP TABLE IF EXISTS ps CASCADE;
CREATE TABLE ps (c1 INT PRIMARY KEY) P
e time of recreating. :-)
[1]
https://www.postgresql.org/message-id/flat/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
Thanks,
Tatsuro Yamada
From 91c09db61c2891cf83b3151f51348dfd02e09744 Mon Sep 17 00:00:00 2001
From: Tatsuro Yamada
Date: Mon, 30 Nov 2020 11:09:00 +0900
Subject:
n progress
Regards,
Tatsuro Yamada
Hi Tomas,
On 2021/01/09 9:01, Tomas Vondra wrote:
On 1/8/21 1:14 AM, Tomas Vondra wrote:
On 1/8/21 12:52 AM, Tatsuro Yamada wrote:
On 2021/01/08 0:56, Tomas Vondra wrote:
On 1/7/21 3:47 PM, Alvaro Herrera wrote:
On 2021-Jan-07, Tomas Vondra wrote:
On 1/7/21 1:46 AM, Tatsuro Yamada wrote
Hi Tomas,
On 2021/01/12 20:08, Tomas Vondra wrote:
On 1/12/21 2:57 AM, Tatsuro Yamada wrote:
Hi Tomas,
On 2021/01/09 9:01, Tomas Vondra wrote:
...>
While working on that, I realized that 'defined' might be a bit
ambiguous, I initially thought it means 'NOT NULL'
I couldn't imagine a suitable term. Therefore,
I'm keeping it as is.
Regards,
Tatsuro Yamada
ve this feature is useful for DBA when they use Extended stats.
For example, the execution plan tuning phase and so on.
Then, I know the patch was reverted. So, I keep going to fix the patch
on the Second iteration. :-D
Regards,
Tatsuro Yamada
| hoge_t_ext
Definition| a, b FROM hoge_t
Ndistinct | requested
Dependencies | requested
MCV | requested
Ndistinct_size| 0 bytes
Dependencies_size | 0 bytes
analyze hoge_t;
-[ RECORD 1 ]-+-
Schema | public
Name | hoge_t_ext
Definition| a, b FROM hoge_t
Ndistinct | built
Dependencies | built
MCV | built
Ndistinct_size| 13 bytes
Dependencies_size | 40 bytes
===
Thanks,
Tatsuro Yamada
use it. NULL means that it doesn't
exists.
+run, and statistics are available to the planner. NULL means that it
doesn't exist.
Agreed.
Thanks,
Tatsuro Yamada
Definition| Ndistinct | Dependencies |
Dependencies
++------+---+--+--
public | hoge1_ext | a, b FROM hoge1 | defined | defined | defined
public | hoge_t_ext | a, b FROM hoge_t | defined | defined | defined
(2 rows)
I'm going to create the WIP patch to use the above queriy.
Any comments welcome. :-D
Thanks,
Tatsuro Yamada
istic_ext only
- Remove these statuses: "required" and "built"
- Add new status: "defined"
- Remove the size columns
- Fix document
I'll create and send the regression test on the next patch if there is
no objection. Is it Okay?
Regards,
Tatsuro Yamad
slversion,
sslcipher, sslbits, sslcompression, ssl_client_dn, ssl_client_serial,
ssl_issuer_dn, gss_auth, gss_princ, gss_enc, leader_pid)
...
Thanks,
Tatsuro Yamada
diff -U3 /home/postgres/PG140/src/test/regress/expected/rules.out
/home/postgres/PG140/src/test/regress/results/rules.out
--- /home/p
email.
I fixed my environment and tested it again, and it was a success. See below:
===
All 202 tests passed.
===
Regards,
Tatsuro Yamada
wed by multiple
people on -hackers. Let's keep moving forward. :-D
I'll send a patch including a regression test on the next patch.
Regards,
Tatsuro Yamada
Hi Tomas,
On 2021/01/20 11:35, Tatsuro Yamada wrote:
Apologies for all the extra work - I haven't realized this flaw when pushing
for showing more stuff :-(
Don't worry about it. We didn't notice the problem even when viewed by multiple
people on -hackers. Let's keep
oping patch.
Then, If possible, could you add Justin to the commit message as a reviewer?
Because I revised the document partly based on his comments.
Finally, As extended stats were more used, this feature becomes more useful.
I hope it helps DBA. :-D
Thanks,
Tatsuro Yamada
t/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com
Thanks,
Tatsuro Yamada
d excludes
those from consideration.
Thanks for your explanation.
Ah, I reread the thread, and I now realized that user visible log messages
are the target to replace. I understood that that elog() for the cases won't
normally occur. Sorry for the noise.
Regards,
Tatsuro Yamada
On 2020/12/04 14:29, Fujii Masao wrote:
On 2020/11/30 15:24, Tatsuro Yamada wrote:
Hi Torikoshi-san,
In this patch, exposing new columns is mandatory, but I think
it's better to make it optional by adding a GUC something
like 'pgss.track_general_custom_plans.
I also feel it
owever, it's okay to divide both information
into two views to use memory effectively.
Regards,
Tatsuro Yamada
able to track all of the plan changes by
checking something view since Plan Stability is important for DBA when
they use PostgreSQL in Mission-critical systems.
I prefer that the feature will be released as a contrib module. :-D
Regards,
Tatsuro Yamada
us to
realize the counter changes, and we can know whether the suspect is
generic_plan or not. So the patch helps DBA, I believe.
Regards,
Tatsuro Yamada
ke a patch later since that's where \dX is.
Regards,
Tatsuro Yamada
Hi justin,
On 2022/01/08 6:56, Justin Pryzby wrote:
On Fri, Jan 07, 2022 at 08:08:57PM +0900, Michael Paquier wrote:
On Fri, Jan 07, 2022 at 06:30:30PM +0900, Tatsuro Yamada wrote:
We should prefix them with pg_catalog as well.
Are you planning to make a patch?
If not, I'll make a patch
Hi,
I found a typo in jsonfuncs.c, probably.
s/an an/an/
Please find attached patch.
Thanks,
Tatsuro Yamada
diff --git a/src/backend/utils/adt/jsonfuncs.c
b/src/backend/utils/adt/jsonfuncs.c
index 511467280f..9961d27df4 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils
Hi Julien and Amit Kapila,
On 2021/04/08 17:33, Julien Rouhaud wrote:
On Thu, Apr 08, 2021 at 10:06:56AM +0900, Tatsuro Yamada wrote:
Hi,
I found a typo in jsonfuncs.c, probably.
s/an an/an/
Please find attached patch.
For the archives' sake, this has been pushed as of 8ffb0
=
For now, I haven't written a document and regression test for that.
I'll create it later.
Thanks,
Tatsuro Yamada
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 9902a4a..dc36c98 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -932,6 +932,9 @@ ex
- Fix the version number check (1 -> 10)
- Fix query to get extended stats info for sort order
- Add handling [Pattern] e.g \dz stts*
- Add document and regression test for \dz
How about using \dX rather than \dz?
Thanks for your suggestion!
I'll replace it if I got consensus. :
t | t
(1 row)
==
Thanks,
Tatsuro Yamada
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index fc16e6c..ace8e5f 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1893,6 +1893,18 @@ testdb=>
unique.
You are right.
The sort key "columns" was not necessary so I removed it.
Attached new patch includes the above two fixes:
- Fix whitespace issue in the documentation part
- Remove unnecessary sort key from the query
(ORDER BY 1, 2, 3, 4 -> ORDER BY 1, 2, 3)
Thanks
quot;Dependencies",
'm' = any(stxkind) AS "MCV"
FROM pg_catalog.pg_statistic_ext
INNER JOIN pg_catalog.pg_class c
ON stxrelid = c.oid
ORDER BY 1, 2, 3;
Thanks,
Tatsuro Yamada
ree patterns: "built", "not built" or nothing (NULL) like these:
- "built": extended stats is defined and built (collected by analyze cmd)
- "not built": extended stats is defined but have not built yet
- nothing (NULL): extended stats is not defined
What do you think about it?
I will send a new patch including :
- Replace "Columns" and "Table" column with "Definition"
- Show the status (built/not built/null) of extended stats by using
pg_statistic_ext_data
Thanks,
Tatsuro Yamada
:
- Replace "Columns" and "Table" column with "Definition"
- Show the status (built/not built/null) of extended stats by
using pg_statistic_ext_data
- Add "\dX+" command to show size of extended stats
Please find the attached file! :-D
Tha
ld be shown only in "verbose" mode (\d+).
I tested your patch on 13beta3 and head (ab3c6d41).
It looks good to me. :-D
Thanks,
Tatsuro Yamada
he RDBMS world so it would be better to divide it.
I'd like to suggest the bellow design of the view.
statname | definition | n-distinct | func-dependencies | mcv |
--+--++---+---|
someobj | (a, b) FROM tab | built | built | built |
sttshoge | (a, b) FROM hoge | required | required | |
sttscross| (a, b) FROM t1,t2| required | | |
Any thoughts?
Thanks,
Tatsuro Yamada
s */
if (visibilityrule)
{
WHEREAND();
appendPQExpBuffer(buf, "%s\n", visibilityrule);
}
}
Thanks,
Tatsuro Yamada
schema qualified.
Thanks for your comments! I understood them:
- all users can show System catalog (pg_catalog. *) is a
specification, so it is not a bug
- visibility and permission are not the same (I confused it before, oops)
Regards,
Tatsuro Yamada
r comments would be appreciated.
Thanks,
Tatsuro Yamada
-- check
CREATE TABLE t01_chk (
product_no integer,
name text,
price numeric CHECK (price > 0)
);
-- unique
CREATE TABLE t02_uniq (
product_no integer UNIQUE,
name text,
price numeric
);
-- primary key
CREATE TABL
\dco
Not implemented yet:
- NOT NULL constraint, and so on (based on pg_attribute)
- Tab completion
- Regression test
- Document
Any comments welcome! :-D
Thanks,
Tatsuro Yamada
From ce46a3fa7252109348876ab9efff8bafcb119730 Mon Sep 17 00:00:00 2001
From: Tatsuro Yamada
Date: Mon, 15 Nov 2021
erything except check constraints).
Thanks! Fixed the both.
Attached file is new patch. It includes:
- Fix help message s/constraint/constraints/
- s/Exclude/Exclusion/
- Remove unused modifier "+"
- Add document for \dco
Thanks,
Tatsuro Yamada
From eee92ee549e49d0b5
hink there is demand.
https://stackoverflow.com/questions/62987794/how-to-list-all-constraints-of-a-table-in-postgresql
Regards,
Tatsuro Yamada
childrows = (*acquirefunc) (childrel, elevel,
rows + numrows, childtargrows,
&trows, &tdrows)
Thanks,
Tatsuro Yamada
I can withdraw my patch.
Anyway, I want to avoid this feature being reverted.
Do you have any ideas to fix the problem?
Thanks,
Tatsuro Yamada
d you committed your patch to
fix the problem. Thanks! I'll test it later. :)
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=da47e43dc32e3c5916396f0cbcfa974b371e4875
Thanks,
Tatsuro Yamada
ostgres|16384|CLUSTER|rebuilding index|16387|10|10|0|0|4
22283|13593|postgres|16384|CLUSTER|performing final
cleanup|16387|10|10|0|0|5
===
Thanks,
Tatsuro Yamada
On 2019/09/27 11:20, Justin Pryzby wrote:
Here's to hoping this is the worst omission in v12.
Justin
Hi Justin,
I share my test result of your patch.
I used two commits REL_12_RC1 and Head, and got a Hunk below:
#REL_12_RC1 (17822c0e4f5ab8093e78f665c9e44766ae648a44)
===
On 2019/02/23 6:02, Robert Haas wrote:
On Fri, Dec 28, 2018 at 3:20 AM Tatsuro Yamada
wrote:
This patch is rebased on HEAD.
I'll tackle revising the patch based on feedbacks next month.
+ Running VACUUM FULL is listed in
pg_stat_progress_cluster
+ view because it uses CLUSTER co
Attached patch is wip patch.
Is it possible to remove the following patch?
Because I registered the patch twice on CF Mar.
https://commitfest.postgresql.org/22/2049/
Thanks,
Tatsuro Yamada
On 2019/03/02 4:15, Robert Haas wrote:
On Thu, Feb 28, 2019 at 11:54 PM Tatsuro Yamada
wrote:
Attached patch is wip patch.
Thanks for your comments! :)
I revised the code and the document.
+ CLUSTER and VACUUM FULL,
showing current progress.
and -> or
Fixed.
+ cert
On 2019/03/02 4:15, Robert Haas wrote:
On Thu, Feb 28, 2019 at 11:54 PM Tatsuro Yamada
wrote:
Attached patch is wip patch.
I rewrote the current design of the progress monitor and also
wrote discussion points in the middle of this email. I'd like to
get any feedback from -ha
Hi David,
On 2019/03/05 17:29, David Steele wrote:
On 3/1/19 7:48 AM, Etsuro Fujita wrote:
(2019/03/01 14:17), Tatsuro Yamada wrote:
Attached patch is wip patch.
Is it possible to remove the following patch?
Because I registered the patch twice on CF Mar.
https://commitfest.postgresql.org
Hi Robert!
On 2019/03/05 11:35, Robert Haas wrote:
On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada
wrote:
=== Current design ===
CLUSTER command uses Index Scan or Seq Scan when scanning the heap.
Depending on which one is chosen, the command will proceed in the
following sequence of phases
On 2019/03/06 1:13, Robert Haas wrote:
On Tue, Mar 5, 2019 at 3:56 AM Tatsuro Yamada
wrote:
=== Discussion points ===
- Progress counter for "3. sorting tuples" phase
- Should we add pgstat_progress_update_param() in tuplesort.c like a
"trace_sort"
On 2019/03/05 17:56, Tatsuro Yamada wrote:
Hi Robert!
On 2019/03/05 11:35, Robert Haas wrote:
On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada
wrote:
=== Current design ===
CLUSTER command uses Index Scan or Seq Scan when scanning the heap.
Depending on which one is chosen, the command will
On 2019/03/06 15:38, Tatsuro Yamada wrote:
On 2019/03/05 17:56, Tatsuro Yamada wrote:
On 2019/03/05 11:35, Robert Haas wrote:
On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada
wrote:
=== Current design ===
CLUSTER command uses Index Scan or Seq Scan when scanning the heap.
Depending on which
Hi Rafia!
On 2019/03/18 20:42, Rafia Sabih wrote:
On Fri, 8 Mar 2019 at 09:14, Tatsuro Yamada
wrote:
Attached file is rebased patch on current HEAD.
I changed a status. :)
Looks like the patch needs a rebase.
I was on the commit fb5806533f9fe0433290d84c9b019399cd69e9c2
PFA reject file in
On 2019/03/19 10:43, Tatsuro Yamada wrote:
Hi Rafia!
On 2019/03/18 20:42, Rafia Sabih wrote:
On Fri, 8 Mar 2019 at 09:14, Tatsuro Yamada
wrote:
Attached file is rebased patch on current HEAD.
I changed a status. :)
Looks like the patch needs a rebase.
I was on the commit
or "writing new heap".
- Fix document
- Revised the patch on the current head:
940311e4bb32a5fe99155052e41179c88b5d48af.
Please find attached files. :)
Regards,
Tatsuro Yamada
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index ac2721c..26a6899 100644
---
Hi Robert and Reviewers!
On 2019/03/26 0:02, Robert Haas wrote:
On Sun, Mar 24, 2019 at 9:02 PM Tatsuro Yamada
wrote:
Please find attached files. :)
Committed. Thanks!
Thank you!
Hope this feature will help DBA and user. :)
Regards,
Tatsuro Yamada
NTT Open Source Software Center
Hi Horiguchi-san, Alvaro, Anthony, Julien and Robert,
On 2019/07/22 17:30, Kyotaro Horiguchi wrote:
Hello.
# It's very good timing, as you came in while I have a time after
# finishing a quite nerve-wrackig task..
At Mon, 22 Jul 2019 15:02:16 +0900, Tatsuro Yamada
wrote in <0876b
Hi Robert and All!
On 2019/08/02 2:48, Robert Haas wrote:> On Thu, Aug 1, 2019 at 4:45 AM Thomas Munro
wrote:
On Tue, Jul 23, 2019 at 4:51 PM Tatsuro Yamada
wrote:
Attached v4 patch file only includes this fix.
I've moved this to the September CF, where it is in "Needs
ure. There's a period at the end when the CLUSTER command
keeps working, but it's gone from pg_stat_progress_cluster.
Thanks for your report.
I'll investigate it. :)
Thanks,
Tatsuro Yamada
Hi Alvaro and All,
On 2019/08/13 14:40, Tatsuro Yamada wrote:
Hi Alvaro!
On 2019/08/02 3:43, Alvaro Herrera wrote:
Hmm, I'm trying this out now and I don't see the index_rebuild_count
ever go up. I think it's because the indexes are built using parallel
index build ... or m
Hi Alvaro,
On 2019/08/13 23:01, Alvaro Herrera wrote:
Hello,
On 2019-Jul-03, Tatsuro Yamada wrote:
My ex-colleague Vinayak created same patch in 2017 [1], and he
couldn't get commit because there are some reasons such as the
patch couldn't handle analyzing Foreign table. Therefore
Hi Michael, Alvaro and Robert!
On 2019/08/14 11:52, Michael Paquier wrote:
On Wed, Aug 14, 2019 at 11:38:01AM +0900, Tatsuro Yamada wrote:
On 2019/08/13 14:40, Tatsuro Yamada wrote:
On 2019/08/02 3:43, Alvaro Herrera wrote:
Hmm, I'm trying this out now and I don't see the index_reb
Hi,
The declaration of estimate_path_cost_size uses baserel, but
the actual definition uses foreignrel. It would be better to sync.
Please find attached a patch.
Tatsuro Yamada
NTT Open Source Software Center
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw
Hi,
I found a variable (queryEnv) which should be added in
ExplainOneQuery_hook because if it is missing, hook function
can't call ExplainOnePlan.
Sorry if this wasn't correct.
Please find attached a patch.
Tatsuro Yamada
NTT Open Source Software Center
diff --git a/src/backen
On 2018/01/12 1:54, Tom Lane wrote:
Tatsuro Yamada writes:
The declaration of estimate_path_cost_size uses baserel, but
the actual definition uses foreignrel. It would be better to sync.
Yeah, the join_conds parameter's been renamed at some point too :-(
the hook function to avoid the same bug because there is no contrib
module using ExplainOneQuery_hook in contrib directory.
(It might unnecessary thing, maybe.)
Regards,
Tatsuro Yamada
On 2018/01/12 2:02, Tom Lane wrote:
Thomas Munro writes:
On Fri, Jan 12, 2018 at 12:16 AM, Tatsuro Yamada
wrote:
I found a variable (queryEnv) which should be added in
ExplainOneQuery_hook because if it is missing, hook function
can't call ExplainOnePlan.
Yeah, I think you
src/backend/utils/misc/guc.c
patching file src/include/utils/plancache.h
patching file src/test/regress/expected/plancache.out
patching file src/test/regress/sql/plancache.sql
- Result of regression test
===
All 186 tests passed.
===
Regards,
Tatsuro Yamada
formation_schema.sgml | wc -l
184
$ grep '\. ' doc/src/sgml/func.sgml | wc -l
577
=====
Therefore, I'm going to leave it as is. :)
Thanks,
Tatsuro Yamada
ng analyze|f|16405|1640|1640|3
Note:
The result on Session2 was shortened for readability.
If you'd like to check the whole result, you can see attached file: "hoge.txt".
==
Thanks,
Tatsuro Yamada
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.s
Hi Alvaro!
On 2019/11/05 22:38, Alvaro Herrera wrote:
On 2019-Nov-05, Tatsuro Yamada wrote:
==
[Session1]
\! pgbench -i
create statistics pg_ext1 (dependencies) ON aid, bid from pgbench_accounts;
create statistics pg_ext2 (mcv) ON aid, bid from pgbench_accounts;
create statistics
his phase, because partitioned
table itself is empty so there's nothing to do in the "acquiring
sample rows" phase.
That's all for now.
Okay! I'll also add the new phase "acquiring inherited sample rows" on
the next patch. :)
Thanks,
Tatsuro Yamada
be added to the total number column to these views? :)
Oops, I made a mistake. :(
What I'd like to say was:
Would it be better to add the total number column to these views? :)
Thanks,
Tatsuro Yamada
Hi Alvaro!
On 2019/11/26 21:22, Alvaro Herrera wrote:
On 2019-Nov-26, Tatsuro Yamada wrote:
I wonder whether we need the total number of ext stats on
pg_stat_progress_analyze or not. As you might know, there is the same
counter on pg_stat_progress_vacuum and pg_stat_progress_cluster.
For
Hi Amit-san,
On Wed, Nov 27, 2019 at 11:04 AM Tatsuro Yamada
wrote:
Regarding to other total number columns,
I'll create another patch to add these columns "index_vacuum_total" and
"index_rebuild_count" on the other views. :)
Maybe you meant "index_rebuild
he document is not updated, I'll fix it later. :)
Attached testcase.sql is for creating base table and partitioning table.
You can check the patch by using the following procedures, easily.
Terminal #1
--
\a \t
select * from pg_stat_progress_analyze; \watch 0.0001
---
Hi Amit-san,
On 2019/11/28 10:59, Amit Langote wrote:
Yamada-san,
Thank you for updating the patch.
On Wed, Nov 27, 2019 at 12:46 PM Tatsuro Yamada
wrote:
But I just remembered I replaced column name "*_table" with "*_relid"
based on Robert's comment three mon
w (as above)
- Renamed the phase name: s/acquiring inh sample rows/acquiring inherited
sample rows/
- Update document
Thanks,
Tatsuro Yamada
Hi Michael,
On 2019/11/27 13:25, Michael Paquier wrote:
On Wed, Nov 27, 2019 at 12:45:41PM +0900, Tatsuro Yamada wrote:
Fixed.
Patch was waiting on input from author, so I have switched it back to
"Needs review", and moved it to next CF while on it as you are working
on it.
Thank
Hi Alvaro and Amit!
On 2019/11/29 9:54, Tatsuro Yamada wrote:
Hi Alvaro!
Hmmm... I understand your opinion but I'd like to get more opinions too. :)
Do you prefer these column names? See below:
Here's my take on it:
pid
datid
datname
relid
phase
sample_
201 0
9 acquiring sample rows 202 0
10 computing stats202 0
11 finalizing analyze 202 0
12 acquiring sample rows 203 0
13 computing stats203 0
14 finalizing analyze 203 0
==
Thanks,
Tatsuro Yamada
e modify
The command is updating pg_class. When this phase is completed,
ANALYZE will end.
# Modified
The command is updating pg_class. When this phase is completed,
ANALYZE will end. In the case of partitioned table,
it might be shown on each partitions.
What do you think that? I'm going to fix it, if you agreed. :)
Thanks,
Tatsuro Yamada
ended stats from the samples
obtained in the previous phase.
+
I suggest:
The command is computing extended statistics from the sample rows obtained
during the table scan.
Will fix.
Thanks for your above useful suggestions. It helps me a lot. :)
Cheers!
Tatsuro Yamada
1 - 100 of 182 matches
Mail list logo
