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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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. :)
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
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
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
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,
.
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.
>
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.
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
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
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 <--
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
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
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
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,
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
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
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?
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
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
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)
{
Alvaro Herrera
Date: Fri, 21 Jun 2019 13:35:13 -0400
Subject: [PATCH v1] Report progress for ANALYZE
---
doc/src/sgml/monitoring.sgml | 129 +++
src/backend/catalog/system_views.sql | 15
src/backend/commands/analyze.c | 55 +++-
src/backend/ut
63 matches
Mail list logo
