RE: index items for pg_stat_progress_xxx views
> Hi, > > The index items for pg_stat_progress_xxx views point to the "Viewing > Statistics" section, but not to the dedicated section (e.g., "ANALYZE > Progress > Reporting") for each view. IMO this is very inconvenient when finding > the section describing each pg_stat_progress_xxx view, from the index. > So what about adding new pointer to the section for each view in the index? > Patch attached. > > BTW, other stats views have both pointers in the index. When setting an , it's better to set the zone attribute to indicate which section it's associated with. For example, pg_stat_progress_analyze Regards, Shinya Kato
RE: index items for pg_stat_progress_xxx views
>>> Hi, >>> >>> The index items for pg_stat_progress_xxx views point to the "Viewing >>> Statistics" section, but not to the dedicated section (e.g., "ANALYZE >>> Progress >>> Reporting") for each view. IMO this is very inconvenient when finding >>> the section describing each pg_stat_progress_xxx view, from the index. >>> So what about adding new pointer to the section for each view in the index? >>> Patch attached. >>> >>> BTW, other stats views have both pointers in the index. >> >> When setting an , it's better to set the zone attribute to >> indicate >which section it's associated with. >> >> For example, >> >> pg_stat_progress_analyze >> > >Thanks for the review! > >I was thinking that the zone attribute doesn't need to be specified because the >indexterm is defined under the section that the indexterm tries to point to. >You >can see the same situation at, for example, the section and indexterm of >pg_stat_database. If I'm missing something, could you tell me why the zone >attribute is necessary in this case? I looked at lines 132-137 of monitoring.sgml, and I saw that zone is set for indexterm after . However, I haven't found the zone set for indexterm after , so you may be right. Regards, Shinya Kato
RE: index items for pg_stat_progress_xxx views
> Hi, > > The index items for pg_stat_progress_xxx views point to the > "Viewing Statistics" section, but not to the dedicated section > (e.g., "ANALYZE Progress > Reporting") for each view. IMO this is very inconvenient when > finding the section describing each pg_stat_progress_xxx view, from the >index. > So what about adding new pointer to the section for each view in the >index? > Patch attached. > > BTW, other stats views have both pointers in the index. When setting an , it's better to set the zone attribute to indicate >>> which section it's associated with. For example, pg_stat_progress_analyze >>> >>> Thanks for the review! >>> >>> I was thinking that the zone attribute doesn't need to be specified >>> because the indexterm is defined under the section that the indexterm >>> tries to point to. You can see the same situation at, for example, >>> the section and indexterm of pg_stat_database. If I'm missing >>> something, could you tell me why the zone attribute is necessary in this >>> case? >> >> I looked at lines 132-137 of monitoring.sgml, and I saw that zone is set for >indexterm after . >> However, I haven't found the zone set for indexterm after , so you may >be right. > >So you agree not to add zone attribute in this case? Yes, I think it's nice. Regards, Shinya Kato
add argument type to postgres_fdw docs
Hi, I add argument type to postgres-fdw parameters in postgres-fdw.sgml. I think this change is kind. Do you think? Regards, Shinya Kato add_argument_type_to_postgres-fdw_docs.patch Description: add_argument_type_to_postgres-fdw_docs.patch
RE: add argument type to postgres_fdw docs
>- extensions >+ extensions (enum) > >Since each value in "extensions" parameter is not limitted like >shared_preload_libraries, its type should be "string"? Yes, I fixed it. > >- fdw_startup_cost >+ fdw_startup_cost (double >+ precision) >- fdw_tuple_cost >+ fdw_tuple_cost (double >+ precision) > >Since "floating point" is used for GUC docs, "floating point" should be used >for >the sake of consistenty, instead? Sure, I changed "double precision" to "floating point". Best regards, Shinya Kato add_argument_type_to_postgres-fdw_docs_v2.patch Description: add_argument_type_to_postgres-fdw_docs_v2.patch
change float4 to floating point about type of autovacuum_vacuum_insert_scale_factor
Hi As shown below, the argument types of autovacuum_vacuum_insert_scale_factor and toast.autovacuum_vacuum_insert_scale_factor are different from the others. --- autovacuum_vacuum_scale_factor, toast.autovacuum_vacuum_scale_factor (floating point) autovacuum_vacuum_insert_scale_factor, toast.autovacuum_vacuum_insert_scale_factor (float4) autovacuum_analyze_scale_factor (floating point) autovacuum_vacuum_cost_delay, toast.autovacuum_vacuum_cost_delay (floating point) https://www.postgresql.org/docs/devel/sql-createtable.html --- In addition, there is this statement. --- autovacuum_vacuum_insert_scale_factor (floating point) https://www.postgresql.org/docs/devel/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-INSERT-SCALE-FACTOR --- So, I thought it was better to be consistent with "floating point", and I created the patch. A similar argument can be found here. https://www.postgresql.org/message-id/CACZ0uYFf_p9BpbjLccx3CA=eM1Hk2Te=uly4iptgluhl-jx...@mail.gmail.com Best Regards, Shinya Kato change_float4_to_floating_point.patch Description: change_float4_to_floating_point.patch
