Seq Scan on t (cost=0.00..1943.00 rows=10210 width=4)
Filter: ((a = 1) AND (b = 1))
Planning:
Ext Stats: s <== Is it acceptable?
If we do not display "Clause" information, I believe that there is
no need to deparse clauses, and therefore no need to improve the deparse
function to enable recursive traversal of expression trees.
To further the discussion, I will modify the patch to display the summary
as shown above and send it to -hackers.
P.S.
I have tried to understand the discussion correctly, but please
let me know if I have misunderstood anything.
Regards,
Tatsuro Yamada
the attached test.sql and result.txt are a test case (incomplete)
and
its results. When the test case is completed, it will be merged into
ext_stats.sql.
Any advice is welcome!
Regards,
Tatsuro Yamada
\set PROMPT1 '%[%033[1m%]%M %n@%/:%>%R%[%033[0m%]%# '
\set HISTFILE ~/.psql_hi
status of the patch for this feature from last month's
commit fest will be
"moving to the next commit fest".
P.S.
Thanks for letting me know, Ilia.
Thanks,
Tatsuro Yamada
Hi All,
I apologize for not being able to continue development due to various
circumstances.
The attached file is the rebased patch.
I will now catch up on the discussion and try to revise the patch.
Regards,
Tatsuro Yamada
On Fri, Jul 19, 2024 at 7:17 PM wrote:
> > On 7/18/24
s that cover the code path? I think only the latter would be fine.
Any advice is appreciated. :-D
P.S.
I'm going to investigate how to use CI this weekend hopefully.
Regards,
Tatsuro Yamada
CREATE FUNCTION
CREATE FUNCTION
CREATE TABLE
INSERT 0 10
Hi Tomas,
The attached patch does not correspond to the above comment.
> But it does solve some of the issues mentioned in previous threads.
>
Oops, I made a mistake sending a patch on my previous email.
Attached patch is the right patch.
Regards,
Tatsuro Yamada
0001-Add-Showing-a
f including it in the next patch.
So there's stuff to do to make this committable, but hopefully this
> review gives you some guidance regarding what/how ;-)
>
Thank you! It helps me a lot!
The attached patch does not correspond to the above comment.
But it does solve some of the issu
Hi, Daniel and Michael,
On Thu, Mar 14, 2024 at 09:32:55AM +0100, Daniel Gustafsson wrote:
> > On 14 Mar 2024, at 07:02, Tatsuro Yamada wrote:
> >> So, I created a patch to fix them.
> >
> > Thanks, applied.
>
> Oops. Thanks.
> --
> Michael
>
Thank y
ash(const void *buff, size_t len, char *hexsum)
...
bool
pg_md5_hash(const void *buff, size_t len, char *hexsum, const char **errstr)
==
Please find attached file.
Regards,
Tatsuro Yamada
NTT Open Source Software Center
fix_synopsis_of_pg_md5_ha
with some limitations.
Please find the attached file.
[1]
https://www.postgresql.org/message-id/flat/8081617b-d80f-ae2b-b79f-ea7e926f9fcf%40enterprisedb.com
Regards,
Tatsuro Yamada
NTT Open Source Software Center
0001-show-stats-in-explain-rebased-on-362de947.patch
Description: 0001-show-stats-
uot;Table".
I fixed the output columns as you proposed.
The current status of this patch is:
- Addressed Dag's comments
- Not implemented yet:
- Tab completion
- Regression test
- NOT NULL constraint, and so on (based on pg_attribute)
Please find attached new
ected".
P.S.
I'll send a new patch addressing Dag's comments in the next email.
Thanks,
Tatsuro Yamada
d stats? E.g. BitmapHeapScan is missing.
* (New) In the case of Group by, we should put Extended stats info under the
Hash/Group Aggregate node (not under Scan node).
* (New) We have to create a regression test including the above test
patterns.
Attached patch:
It is a rebased version on the hea
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
ke a patch later since that's where \dX is.
Regards,
Tatsuro Yamada
hink there is demand.
https://stackoverflow.com/questions/62987794/how-to-list-all-constraints-of-a-table-in-postgresql
Regards,
Tatsuro Yamada
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
\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
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
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
s */
if (visibilityrule)
{
WHEREAND();
appendPQExpBuffer(buf, "%s\n", visibilityrule);
}
}
Thanks,
Tatsuro Yamada
Hi Magnus!
I found other functions that we should add "pg_catalog" prefix in
describe.c. This fix is similar to the following commit.
Yup, that's correct. Applied and backpatched to 14 (but it won't be in the 14.0
release).
Thank you!
Regards,
Tatsuro Yamada
quot;pg_catalog." prefix
=
Please find attached the patch.
Regards,
Tatsuro Yamada
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 90ff649..a33d77c 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -2881,7 +2881,7 @@ describeOneTableDetails(co
Hi Tomas and Justin,
On 2021/07/27 4:26, Tomas Vondra wrote:
Hi,
I've pushed the last version of the fix, including the regression tests etc.
Backpatch to 14, where \dX was introduced.
Thank you!
Regards,
Tatsuro Yamada
assed.
===
Next time I create a feature on psql, I will be careful to add
a check for schema visibility rules. :-D
Thanks,
Tatsuro Yamada
luck in your future career! :-D
See you at the Japanese PG developers' meetup.
Thanks,
Tatsuro Yamada
Hi,
On 2021/06/09 16:23, Fujii Masao wrote:
On 2021/06/09 15:58, Tatsuro Yamada wrote:
This may not be important at this time since it is a
PoC patch, but I would like to inform you that there
was a line that contained multiple spaces instead of tabs.
$ git diff --check
src/backend/access
/transam/xlogarchive.c:465: trailing whitespace.
+
Regards,
Tatsuro Yamada
Hi Horiguchi-san,
On 2021/06/09 11:47, Kyotaro Horiguchi wrote:
On 2021/06/08 18:19, Tatsuro Yamada wrote:
I've tried your patch. Unfortunately, it didn't seem to have any good
effect on the script I sent to reproduce the problem.
Oops! The patch forgot about history files.
I c
mer's problem has already been solved, so it's ok. I've
emailed -hackers with the aim of preventing users from encountering
the same problem.
Regards,
Tatsuro Yamada
do the same.
Anyway I re-launched a new standalone thread.
https://www.postgresql.org/message-id/20210607.173108.348241508233844279.horikyota.ntt%40gmail.com
Thank you!
Regards,
Tatsuro Yamada
On 2021/06/07 16:31, Kyotaro Horiguchi wrote:
At Mon, 07 Jun 2021 16:13:08 +0900, Tatsuro Yamada
wrote in
I just noticed that this thread is still tied to another thread
(it's not an independent thread). To fix that, it may be better to
create a new thread again.
Mmm. Maybe my m
h tomorrow.
I just noticed that this thread is still tied to another thread
(it's not an independent thread). To fix that, it may be better to
create a new thread again.
Regards,
Tatsuro Yamada
ight
be overkill?!).
Regards,
Tatsuro Yamada
r
archive_command. If I remember correctly, the guide provided by
NTT OSS Center that we are using does not recommend using the test command.
Regards,
Tatsuro Yamada
2021-06-01 13:11:50.168 JST [3041] LOG: starting PostgreSQL 14beta1 on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150
I think we should put some notes
in postgresql.conf or in the documentation. For example, something
like this:
Note: If you use archive_mode=always, the archive_command on the standby side should not
be used "test ! -f".
Regards,
Tatsuro Yamada
le as is. If this behavior is a specification, it would be
better not to write the test command as a usage example.
Or maybe there should be a note that the test command should not be used
when archive_mode=always. Maybe, I'm missing something, sorry.
Regards,
Tatsuro Yamada
set -v
pg_ctl s
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
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
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
rfect. Thanks for your time on this.
Thanks for fixing the problem! :-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
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
owever, it's okay to divide both information
into two views to use memory effectively.
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
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
t/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com
Thanks,
Tatsuro Yamada
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
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
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
email.
I fixed my environment and tested it again, and it was a success. See below:
===
All 202 tests passed.
===
Regards,
Tatsuro Yamada
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
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
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
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
| 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
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
I couldn't imagine a suitable term. Therefore,
I'm keeping it as is.
Regards,
Tatsuro Yamada
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'
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,
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
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,
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
n progress
Regards,
Tatsuro Yamada
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:
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
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
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
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
=# \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
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
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
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
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
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
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
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
:
- 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
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
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
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
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=>
- 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. :
=
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
lect count(*) from pg_class where oid >$1;
prepare_time| 2020-05-21 17:41:16.134362+09
parameter_types | {oid}
from_sql| t
is_generic_plan | t <= True
Thanks,
Tatsuro Yamada
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index 80d6df8ac1..63de
e progress (Álvaro
Herrera, Tatsuro Yamada)
+ Add system view pg_stat_progress_analyze to report analyze progress (Álvaro
Herrera, Tatsuro Yamada, Vinayak Pokale)
===
Done.
Hi Bruce,
Thank you!
Regards,
Tatsuro Yamada
ss (Álvaro
Herrera, Tatsuro Yamada)
+ Add system view pg_stat_progress_analyze to report analyze progress (Álvaro
Herrera, Tatsuro Yamada, Vinayak Pokale)
===
[1]
https://www.postgresql.org/message-id/20190813140127.GA4933%40alvherre.pgsql
Thanks,
Tatsuro Yamada
Hi Julien,
On 2020/04/02 22:25, Julien Rouhaud wrote:
New conflict, rebased v9 attached.
I tested the patch on the head (c7654f6a3) and
the result was fine. See below:
$ make installcheck-world
=
All 1 tests passed.
=
Regards,
Tatsuro Yamada
Hi,
On 2020/01/24 23:44, Amit Langote wrote:
On Fri, Jan 24, 2020 at 6:47 AM Alvaro Herrera wrote:
On 2020-Jan-22, Tatsuro Yamada wrote:
P.S.
Next up is progress reporting for query execution?!
Actually, I think it's ALTER TABLE.
+1. Existing infrastructure might be enough to
execution?!
To create it, I guess that it needs to improve
progress reporting infrastructure.
Thanks,
Tatsuro Yamada
Hi All,
*All* phases are repeated in this case, not not just "finalizing
analyze", because ANALYZE repeatedly runs for each partition after the
parent partitioned table's ANALYZE finishes. ANALYZE's documentation
mentions that analyzing a partitioned table also analyzes all of its
partitions, s
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
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
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
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_
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
w (as above)
- Renamed the phase name: s/acquiring inh sample rows/acquiring inherited
sample rows/
- Update document
Thanks,
Tatsuro Yamada
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
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 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
1 - 100 of 186 matches
Mail list logo
