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 cover ALTER
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 cover ALTER TABLE's
needs, whereas we will very li
On 2020-Jan-22, Tatsuro Yamada wrote:
> Thanks for reviewing and committing the patch!
> Hope this helps DBA. :-D
I'm sure it does!
> P.S.
> Next up is progress reporting for query execution?!
Actually, I think it's ALTER TABLE.
Also, things like VACUUM could report the progress of the index b
On Wed, Jan 22, 2020 at 03:06:52PM +0900, Amit Langote wrote:
> Oops, really attached this time.
Thanks, applied. There were clearly two grammar mistakes in the first
patch sent by Justin. And your suggestions look fine to me. On top
of that, I have noticed that the indentation of the two table
On Wed, Jan 22, 2020 at 2:52 PM Amit Langote wrote:
>
> On Fri, Jan 17, 2020 at 12:19 AM Justin Pryzby wrote:
> >
> > On Wed, Jan 15, 2020 at 02:11:10PM -0300, Alvaro Herrera wrote:
> > > I just pushed this after some small extra tweaks.
> > >
> > > Thanks, Yamada-san, for seeing this to completi
On Fri, Jan 17, 2020 at 12:19 AM Justin Pryzby wrote:
>
> On Wed, Jan 15, 2020 at 02:11:10PM -0300, Alvaro Herrera wrote:
> > I just pushed this after some small extra tweaks.
> >
> > Thanks, Yamada-san, for seeing this to completion!
>
> Find attached minor fixes to docs - sorry I didn't look ear
Hi Alvaro and All reviewers,
On 2020/01/16 2:11, Alvaro Herrera wrote:
I just pushed this after some small extra tweaks.
Thanks, Yamada-san, for seeing this to completion!
Thanks for reviewing and committing the patch!
Hope this helps DBA. :-D
P.S.
Next up is progress reporting for query exe
On Wed, Jan 15, 2020 at 02:11:10PM -0300, Alvaro Herrera wrote:
> I just pushed this after some small extra tweaks.
>
> Thanks, Yamada-san, for seeing this to completion!
Find attached minor fixes to docs - sorry I didn't look earlier.
Possibly you'd also want to change the other existing instan
I just pushed this after some small extra tweaks.
Thanks, Yamada-san, for seeing this to completion!
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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
Hi Amit-san,
>>> 1)
For now, I'm not sure it should be set current_child_table_relid to zero
when the current phase is changed from "acquiring inherited sample rows" to
"computing stats". See bellow.
In the upthread discussion [1], Robert asked to *not* do such things,
that is, resetting
Yamada-san,
On Fri, Dec 6, 2019 at 3:24 PM Tatsuro Yamada
wrote:
>>> 1)
> >>> For now, I'm not sure it should be set current_child_table_relid to zero
> >>> when the current phase is changed from "acquiring inherited sample rows"
> >>> to
> >>> "computing stats". See bellow.
> >>
> >> In the u
Hi Amit-san,
I wonder two things below. What do you think?
1)
For now, I'm not sure it should be set current_child_table_relid to zero
when the current phase is changed from "acquiring inherited sample rows" to
"computing stats". See bellow.
In the upthread discussion [1], Robert asked to *
Hi Amit-san,
Thanks for your comments!
Attached patch is the revised patch. :)
I wonder two things below. What do you think?
1)
For now, I'm not sure it should be set current_child_table_relid to zero
when the current phase is changed from "acquiring inherited sample rows" to
"computing stats
Yamada-san,
On Fri, Nov 29, 2019 at 5:45 PM Tatsuro Yamada
wrote:
> Attached patch is the revised patch. :)
>
> I wonder two things below. What do you think?
>
> 1)
> For now, I'm not sure it should be set current_child_table_relid to zero
> when the current phase is changed from "acquiring inher
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_blks_total
sam
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.
Thanks for your
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_blks_total
sample_blks_scanned
ext_stats_total
ext_stats_computed
chi
On 2019-Nov-28, Tatsuro Yamada wrote:
> 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_blks_total
sample_blks_scanned
ext_stats_total
ext_sta
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 months ago, see below:
/me review
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 months ago, see below:
>
> > /me reviews.
> >
> > + scanning_table
> >
> > I think t
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.
--
Michael
signature.asc
Description: PGP signature
Hi Amit-san!
I think include_children and current_relid are not enough to
understand the progress of analyzing inheritance trees, because even
with current_relid being updated, I can't tell how many more there
will be. I think it'd be better to show the total number of children
and the number o
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_total"?
Yeah, you are right! :)
On 2019-Nov-27, Amit Langote wrote:
> On Tue, Nov 26, 2019 at 9:22 PM 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
> > > >
Yamada-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_total"?
Thanks,
Amit
On Tue, Nov 26, 2019 at 9:22 PM 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_progres
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 examp
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 example, index_vacuum_count and index_rebuild_c
Hi Amit-san,
Related to the above,
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 example, index_vacuum_count and index_rebuild_count.
Would it b
Hi Amit-san!
Thanks for your comments!
I have looked at the patch and here are some comments.
I think include_children and current_relid are not enough to
understand the progress of analyzing inheritance trees, because even
with current_relid being updated, I can't tell how many more there
wi
Yamada-san,
Thanks for working on this.
On Wed, Nov 6, 2019 at 2:50 PM Tatsuro Yamada
wrote:
> I revised the patch as following because I realized counting the types of ext
> stats is not useful for users.
>
> - Attached new patch counts a number of ext stats instead the types of ext
> stats.
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 p
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 pg_ext3 (ndistinct) ON aid, bid from pgbench_ac
Hi Alvaro, vignesh,
I rebased the patch on 2a4d96eb, and added new column
"ext_compute_count" in pg_stat_progress_analyze vie to
report a number of computing extended stats.
It is like a "index_vacuum_count" in vacuum progress reporter or
"index_rebuild_count" in cluster progress reporter. :)
Pl
Hi vignesh!
On 2019/09/17 20:51, vignesh C wrote:
On Thu, Sep 5, 2019 at 2:31 AM Alvaro Herrera wrote:
There were some minor problems in v5 -- bogus Docbook as well as
outdated rules.out, small "git diff --check" complaint about whitespace.
This v6 (on today's master) fixes those, no other c
On Thu, Sep 5, 2019 at 2:31 AM Alvaro Herrera wrote:
>
> There were some minor problems in v5 -- bogus Docbook as well as
> outdated rules.out, small "git diff --check" complaint about whitespace.
> This v6 (on today's master) fixes those, no other changes.
>
+
+ The command is preparin
Hi Alvaro,
There were some minor problems in v5 -- bogus Docbook as well as
outdated rules.out, small "git diff --check" complaint about whitespace.
This v6 (on today's master) fixes those, no other changes.
Thanks for fixing that. :)
I'll test it later.
I think we have to address the fol
There were some minor problems in v5 -- bogus Docbook as well as
outdated rules.out, small "git diff --check" complaint about whitespace.
This v6 (on today's master) fixes those, no other changes.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
it looks like postgres_fdw
Actually, I've changed my mind.
Even if there is no FDW support, Progress report for ANALYZE is still useful.
Therefore, FDW support would be preferable but not required for committing
the patch, I believe. :)
Thanks,
Tatsuro Yamada
On 2019-Aug-14, Etsuro Fujita wrote:
> On Tue, Aug 13, 2019 at 11:01 PM Alvaro Herrera
> wrote:
> > On the subject of FDW support: I did look into supporting that before
> > submitting this. I think it's not academically difficult: just have the
> > FDW's acquire_sample_rows callback invoke the
Hi,
On Tue, Aug 13, 2019 at 11:01 PM Alvaro Herrera
wrote:
> On the subject of FDW support: I did look into supporting that before
> submitting this. I think it's not academically difficult: just have the
> FDW's acquire_sample_rows callback invoke the update_param functions
> once in a while.
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, I wonder
> whether your patch is able to do that or not.
> [1
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 review" state.
/m
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 review" state.
/me reviews.
+ scanning_table
I think this should b
On Tue, Jul 23, 2019 at 4:51 PM Tatsuro Yamada
wrote:
> Attached v4 patch file only includes this fix.
Hello all,
I've moved this to the September CF, where it is in "Needs review" state.
Thanks,
--
Thomas Munro
https://enterprisedb.com
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 <0876b4fe-26fb-ca
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
<0876b4fe-26fb-ca32-f179-c696fa3dd...@nttcom.co.jp>
> >> 3785|13599|postgres|16384|f|16384|analyzing complete|0|0 <-- Ad
Hi Horiguchi-san!
On 2019/07/11 19:56, Kyotaro Horiguchi wrote:
Hello.
At Tue, 9 Jul 2019 17:38:44 +0900, Tatsuro Yamada
wrote in <244cb241-168b-d6a9-c45f-a80c34cdc...@nttcom.co.jp>
Hi Alvaro, Anthony, Julien and Robert,
On 2019/07/09 3:47, Julien Rouhaud wrote:
On Mon, Jul 8, 2019 at 8:4
Hello.
At Tue, 9 Jul 2019 17:38:44 +0900, Tatsuro Yamada
wrote in
<244cb241-168b-d6a9-c45f-a80c34cdc...@nttcom.co.jp>
> Hi Alvaro, Anthony, Julien and Robert,
>
> On 2019/07/09 3:47, Julien Rouhaud wrote:
> > On Mon, Jul 8, 2019 at 8:44 PM Robert Haas
> > wrote:
> >>
> >> On Mon, Jul 8, 2019
On Wed, Jul 10, 2019 at 9:26 AM Alvaro Herrera wrote:
> On 2019-Jul-10, Robert Haas wrote:
> > On Tue, Jul 9, 2019 at 6:12 PM Alvaro Herrera
> > wrote:
> > > Hmm, ok. In CREATE INDEX, we use the block counters multiple times.
> >
> > Why do we do that?
>
> Because we scan the table first, then
On 2019-Jul-10, Robert Haas wrote:
> On Tue, Jul 9, 2019 at 6:12 PM Alvaro Herrera
> wrote:
> > Hmm, ok. In CREATE INDEX, we use the block counters multiple times.
>
> Why do we do that?
Because we scan the table first, then the index, then the table again
(last two for the validation phase o
On Tue, Jul 9, 2019 at 6:12 PM Alvaro Herrera wrote:
> Hmm, ok. In CREATE INDEX, we use the block counters multiple times.
Why do we do that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 2019-Jul-08, Robert Haas wrote:
> On Mon, Jul 8, 2019 at 2:18 PM Alvaro Herrera
> wrote:
> > Yeah, I got the impression that that was determined to be the desirable
> > behavior, so I made it do that, but I'm not really happy about it
> > either. We're not too late to change the CREATE INDEX
Hi Alvaro, Anthony, Julien and Robert,
On 2019/07/09 3:47, Julien Rouhaud wrote:
On Mon, Jul 8, 2019 at 8:44 PM Robert Haas wrote:
On Mon, Jul 8, 2019 at 2:18 PM Alvaro Herrera wrote:
Yeah, I got the impression that that was determined to be the desirable
behavior, so I made it do that, but
On Mon, Jul 8, 2019 at 8:44 PM Robert Haas wrote:
>
> On Mon, Jul 8, 2019 at 2:18 PM Alvaro Herrera
> wrote:
> > Yeah, I got the impression that that was determined to be the desirable
> > behavior, so I made it do that, but I'm not really happy about it
> > either. We're not too late to change
On Mon, Jul 8, 2019 at 2:18 PM Alvaro Herrera wrote:
> Yeah, I got the impression that that was determined to be the desirable
> behavior, so I made it do that, but I'm not really happy about it
> either. We're not too late to change the CREATE INDEX behavior, but
> let's discuss what is it that
On 2019-Jul-08, Robert Haas wrote:
> On Mon, Jul 8, 2019 at 5:29 AM Tatsuro Yamada
> wrote:
> > 17520|13599|postgres|16387|f|16387|scanning table|4425|4425
> > 17520|13599|postgres|16387|f|16387|analyzing sample|0|0
> > 17520|13599|postgres|16387|f|16387||0|0 <-- Is it Okay??
>
> Why do we zero
On Mon, Jul 8, 2019 at 5:29 AM Tatsuro Yamada
wrote:
> 17520|13599|postgres|16387|f|16387|scanning table|4425|4425
> 17520|13599|postgres|16387|f|16387|analyzing sample|0|0
> 17520|13599|postgres|16387|f|16387||0|0 <-- Is it Okay??
Why do we zero out the block numbers when we switch phases? The
Hi Alvaro,
I'll review your patch in this week. :)
I tested your patch on 6b854896.
Here is a result. See below:
-
[Session #1]
create table hoge as select * from generate_series(1, 100) a;
analyze verbose hoge;
[Session #2]
\a
\t
s
Hi Alvaro!
On 2019/06/22 3:52, Alvaro Herrera wrote:
Hello
Here's a patch that implements progress reporting for ANALYZE.
Sorry for the late reply.
My email address was changed to tatsuro.yamada...@nttcom.co.jp.
I have a question about your patch.
My ex-colleague Vinayak created same patch i
Hi,
In monitoring.sgml, "a" is missing in "row for ech backend that is
currently running that command[...]".
Anthony
On Tuesday, July 2, 2019, Julien Rouhaud wrote:
> On Fri, Jun 21, 2019 at 8:52 PM Alvaro Herrera
wrote:
>>
>> Here's a patch that implements progress reporting for ANALYZE.
>
> P
On Fri, Jun 21, 2019 at 8:52 PM Alvaro Herrera wrote:
>
> Here's a patch that implements progress reporting for ANALYZE.
Patch applies, code and doc and compiles cleanly. I have few comments:
@@ -512,7 +529,18 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
if (numrows > 0)
{
Hello
Here's a patch that implements progress reporting for ANALYZE.
Thanks
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 572fea555bc1c9d3512f7806aed6b97a374199eb Mon Sep 17 00:00:00 2001
From: Alvaro H
64 matches
Mail list logo
