Re: progress report for ANALYZE - Mailing list pgsql-hackers

From Tatsuro Yamada
Subject Re: progress report for ANALYZE
Date
Msg-id 74e4c0f9-3a7b-5023-97e6-a2a1f56aa709@nttcom.co.jp_1
Whole thread Raw
In response to Re: progress report for ANALYZE  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: progress report for ANALYZE  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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
>>
https://www.postgresql.org/message-id/flat/968b4eda-2417-8b7b-d468-71643cf088b6%40openscg.com#574488592fcc9708c38fa44b0dae9006
> 
> 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!


Thanks!
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
preferablebut not required for committing
 
the patch, I believe. :)


Thanks,
Tatsuro Yamada






pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Alexander Korotkov
Date:
Subject: Re: Don't like getObjectDescription results for pg_amop/pg_amproc