Hello,
I am not really willing to show up as the picky guy here, but could it be
possible to receive those patches as attached to emails instead of having them
referenced by URL? I imagine that you are directly using the nabble interface.
Just configured a new mail client for nabble, did not
On 2015-07-16 AM 05:18, Rahila Syed wrote:
GUC parameter 'pgstat_track_progress' is currently PGC_SUSET in line with
'track_activities' GUC parameter.
Naming the GUC pgstat* seems a little inconsistent. It could be called,
say,
Hello,
Please find attached updated patch with an interface to calculate command
progress in pgstat.c. This interface currently implements VACUUM progress
tracking .
A column named percent_complete has been added in pg_stat_activity to
report progress.
VACUUM calls the progress calculation
Hello,
TBH, I think that designing this as a hook-based solution is adding a whole
lot of complexity for no value. The hard parts of the problem are collecting
the raw data and making the results visible to users, and both of those
require involvement of the core code. Where is the benefit
Hello,
Unless I am missing something, I guess you can still keep the actual code that
updates counters outside the core if you adopt an approach that Simon suggests.
Yes. The code to extract progress information from VACUUM and storing in shared
memory can be outside core even with
Syed, Rahila rahila.s...@nttdata.com writes:
Hello,
Unless I am missing something, I guess you can still keep the actual code
that updates counters outside the core if you adopt an approach that Simon
suggests.
Yes. The code to extract progress information from VACUUM and storing in
On 2015-07-02 PM 11:00, Syed, Rahila wrote:
Hello,
Unless I am missing something, I guess you can still keep the actual code
that updates counters outside the core if you adopt an approach that Simon
suggests.
Yes. The code to extract progress information from VACUUM and storing in
On 2 July 2015 at 03:00, Rahila Syed rahilasye...@gmail.com wrote:
Yes, I suggest just a single column on pg_stat_activity called
pct_complete
Reporting remaining time also can be crucial to make decisions regarding
continuing or aborting VACUUM.
The same has been suggested in the thread
On 2015-07-02 AM 11:41, Rahila Syed wrote:
Hello,
I though about the possibilities of progress visualization - and one
possibility is one or two special column in pg_stat_activity table - this
info can be interesting for VACUUM started by autovacuum too.
Thank you for suggestion. The
Hello,
Thank you for suggestion. The design with hooks and a separate view was
mainly to keep most of the code outside core as the feature proposed is
specific to VACUUM command. Also, having a separate view can give more
flexibility in terms of displaying various progress parameters.
FWIW ,there
Le 2 juil. 2015 7:28 AM, Simon Riggs si...@2ndquadrant.com a écrit :
On 2 July 2015 at 03:00, Rahila Syed rahilasye...@gmail.com wrote:
Yes, I suggest just a single column on pg_stat_activity called
pct_complete
Reporting remaining time also can be crucial to make decisions regarding
Hello,
Thank you for suggestions.
Yes, I suggest just a single column on pg_stat_activity called pct_complete
Reporting remaining time also can be crucial to make decisions regarding
continuing or aborting VACUUM.
The same has been suggested in the thread below,
Hello,
I though about the possibilities of progress visualization - and one
possibility is one or two special column in pg_stat_activity table - this
info can be interesting for VACUUM started by autovacuum too.
Thank you for suggestion. The design with hooks and a separate view was
mainly to
On Tue, Jun 30, 2015 at 7:37 PM, Rahila Syed rahilasye...@gmail.com wrote:
Hello Hackers,
Following is a proposal for feature to calculate VACUUM progress.
Use Case : Measuring progress of long running VACUUMs to help DBAs make
informed decision
whether to continue running VACUUM or abort
On Tue, Jun 30, 2015 at 1:07 PM, Rahila Syed rahilasye...@gmail.com wrote:
Hello Hackers,
Following is a proposal for feature to calculate VACUUM progress.
Use Case : Measuring progress of long running VACUUMs to help DBAs make
informed decision
whether to continue running VACUUM or abort
Hi
2015-06-30 9:37 GMT+02:00 Rahila Syed rahilasye...@gmail.com:
Hello Hackers,
Following is a proposal for feature to calculate VACUUM progress.
interesting idea - I like to see it integrated to core.
Use Case : Measuring progress of long running VACUUMs to help DBAs make
informed
On 30 June 2015 at 08:52, Pavel Stehule pavel.steh...@gmail.com wrote:
I though about the possibilities of progress visualization - and one
possibility is one or two special column in pg_stat_activity table - this
info can be interesting for VACUUM started by autovacuum too.
Yes, I suggest
201 - 217 of 217 matches
Mail list logo
