Re: progress report for ANALYZE

From: Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: progress report for ANALYZE
Date: 2019-08-15 01:45:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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, I wonder
>> whether your patch is able to do that or not.
>> [1] ANALYZE command progress checker
> So just now I went to check the jold thread (which I should have
> searched for before writing my own implementation!). It seems clear
> that many things are pretty similar in both patch, but I think for the
> most part they are similar just because the underlying infrastructure
> imposes a certain design already, rather than there being any actual
> copying. (To be perfectly clear: I didn't even know that this patch
> existed and I didn't grab any code from there to produce my v1.)

I know your patch was not based on Vinayak's old patch because
coding style is different between him and you.

> However, you've now modified the patch from what I submitted and I'm
> wondering if you've taken any inspiration from Vinayak's old patch. If
> so, it seems fair to credit him as co-author in the commit message. It
> would be good to get his input on the current patch, though.

Yeah, I'm happy if you added his name as co-authors because I checked
the document including his old patch as a reference. :)

> I have not looked at the current version of the patch yet, but I intend
> to do so during the upcoming commitfest.
> Thanks for moving this forward!

Committing the patch on PG13 makes me happy because Progress reporting
features are important for DBA. :)

> 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. Sadly, in practical terms 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. :)

Tatsuro Yamada

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2019-08-15 02:20:42 Re: Don't like getObjectDescription results for pg_amop/pg_amproc
Previous Message Bruce Momjian 2019-08-15 01:19:44 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)