"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
> shared memory can be outside core even with pg_stat_activity as a user
> interface.
>> Whatever the view (existing/new), any related counters would have a valid
>> (non-NULL) value when read off the view iff hooks are set perhaps because
>> you have an extension that sets them.
>> I guess that means any operation that "supports" progress tracking would
>> have an extension with suitable hooks implemented.
> Do you mean to say , any operation/application that want progress tracking
> feature will dynamically load the progress checker module which will set the
> hooks for progress reporting?
> If yes , unless I am missing something such dynamic loading cannot happen if
> we use pg_stat_activity as it gets values from shared memory. Module has to
> be a shared_preload_library
> to allocate a shared memory. So this will mean the module can be loaded
>> only at server restart. Am I missing something?
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
from pushing some trivial intermediate arithmetic into an external module?
If there's any at all, it's certainly not enough to justify problems such
as you mention here.
So I'd just create a "pgstat_report_percent_done()" type of interface in
pgstat.c and then teach VACUUM to call it directly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
