On 11/19/15 7:29 PM, Amit Langote wrote:
Another option is to provide the means for the index scan routines to
>report their progress. Maybe every index AM won't use it, but it'd
>certainly be a lot better than staring at a long_running boolean.
The boolean would be a workaround for sure. I'm also slightly tempted by
the idea of instrumenting vacuum scans of individual index AM's bulkdelete
methods. One precedent is how vacuum_delay_point() are sprinkled around in
the code. Another problem to solve would be to figure out how to pass
progress parameters around - via some struct or could they be globals just
like VacuumCost* variables are...

It just occurred to me that we could do the instrumentation in lazy_tid_reaped(). It might seem bad to do in increment for every tuple in an index, but we're already doing a bsearch over the dead tuple list. Presumably that's going to be a lot more expensive than an increment operation.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to