begriffs open source - ai-pg/blob - full-docs/txt/progress-reporting.txt

   1
   2 27.4. Progress Reporting #
   3
   4    27.4.1. ANALYZE Progress Reporting
   5    27.4.2. CLUSTER Progress Reporting
   6    27.4.3. COPY Progress Reporting
   7    27.4.4. CREATE INDEX Progress Reporting
   8    27.4.5. VACUUM Progress Reporting
   9    27.4.6. Base Backup Progress Reporting
  10
  11    PostgreSQL has the ability to report the progress of certain commands
  12    during command execution. Currently, the only commands which support
  13    progress reporting are ANALYZE, CLUSTER, CREATE INDEX, VACUUM, COPY,
  14    and BASE_BACKUP (i.e., replication command that pg_basebackup issues to
  15    take a base backup). This may be expanded in the future.
  16
  17 27.4.1. ANALYZE Progress Reporting #
  18
  19    Whenever ANALYZE is running, the pg_stat_progress_analyze view will
  20    contain a row for each backend that is currently running that command.
  21    The tables below describe the information that will be reported and
  22    provide information about how to interpret it.
  23
  24    Table 27.38. pg_stat_progress_analyze View
  25
  26    Column Type
  27
  28    Description
  29
  30    pid integer
  31
  32    Process ID of backend.
  33
  34    datid oid
  35
  36    OID of the database to which this backend is connected.
  37
  38    datname name
  39
  40    Name of the database to which this backend is connected.
  41
  42    relid oid
  43
  44    OID of the table being analyzed.
  45
  46    phase text
  47
  48    Current processing phase. See Table 27.39.
  49
  50    sample_blks_total bigint
  51
  52    Total number of heap blocks that will be sampled.
  53
  54    sample_blks_scanned bigint
  55
  56    Number of heap blocks scanned.
  57
  58    ext_stats_total bigint
  59
  60    Number of extended statistics.
  61
  62    ext_stats_computed bigint
  63
  64    Number of extended statistics computed. This counter only advances when
  65    the phase is computing extended statistics.
  66
  67    child_tables_total bigint
  68
  69    Number of child tables.
  70
  71    child_tables_done bigint
  72
  73    Number of child tables scanned. This counter only advances when the
  74    phase is acquiring inherited sample rows.
  75
  76    current_child_table_relid oid
  77
  78    OID of the child table currently being scanned. This field is only
  79    valid when the phase is acquiring inherited sample rows.
  80
  81    delay_time double precision
  82
  83    Total time spent sleeping due to cost-based delay (see Section 19.10.2,
  84    in milliseconds (if track_cost_delay_timing is enabled, otherwise
  85    zero).
  86
  87    Table 27.39. ANALYZE Phases
  88    Phase Description
  89    initializing The command is preparing to begin scanning the heap. This
  90    phase is expected to be very brief.
  91    acquiring sample rows The command is currently scanning the table given
  92    by relid to obtain sample rows.
  93    acquiring inherited sample rows The command is currently scanning child
  94    tables to obtain sample rows. Columns child_tables_total,
  95    child_tables_done, and current_child_table_relid contain the progress
  96    information for this phase.
  97    computing statistics The command is computing statistics from the
  98    sample rows obtained during the table scan.
  99    computing extended statistics The command is computing extended
 100    statistics from the sample rows obtained during the table scan.
 101    finalizing analyze The command is updating pg_class. When this phase is
 102    completed, ANALYZE will end.
 103
 104 Note
 105
 106    Note that when ANALYZE is run on a partitioned table without the ONLY
 107    keyword, all of its partitions are also recursively analyzed. In that
 108    case, ANALYZE progress is reported first for the parent table, whereby
 109    its inheritance statistics are collected, followed by that for each
 110    partition.
 111
 112 27.4.2. CLUSTER Progress Reporting #
 113
 114    Whenever CLUSTER or VACUUM FULL is running, the
 115    pg_stat_progress_cluster view will contain a row for each backend that
 116    is currently running either command. The tables below describe the
 117    information that will be reported and provide information about how to
 118    interpret it.
 119
 120    Table 27.40. pg_stat_progress_cluster View
 121
 122    Column Type
 123
 124    Description
 125
 126    pid integer
 127
 128    Process ID of backend.
 129
 130    datid oid
 131
 132    OID of the database to which this backend is connected.
 133
 134    datname name
 135
 136    Name of the database to which this backend is connected.
 137
 138    relid oid
 139
 140    OID of the table being clustered.
 141
 142    command text
 143
 144    The command that is running. Either CLUSTER or VACUUM FULL.
 145
 146    phase text
 147
 148    Current processing phase. See Table 27.41.
 149
 150    cluster_index_relid oid
 151
 152    If the table is being scanned using an index, this is the OID of the
 153    index being used; otherwise, it is zero.
 154
 155    heap_tuples_scanned bigint
 156
 157    Number of heap tuples scanned. This counter only advances when the
 158    phase is seq scanning heap, index scanning heap or writing new heap.
 159
 160    heap_tuples_written bigint
 161
 162    Number of heap tuples written. This counter only advances when the
 163    phase is seq scanning heap, index scanning heap or writing new heap.
 164
 165    heap_blks_total bigint
 166
 167    Total number of heap blocks in the table. This number is reported as of
 168    the beginning of seq scanning heap.
 169
 170    heap_blks_scanned bigint
 171
 172    Number of heap blocks scanned. This counter only advances when the
 173    phase is seq scanning heap.
 174
 175    index_rebuild_count bigint
 176
 177    Number of indexes rebuilt. This counter only advances when the phase is
 178    rebuilding index.
 179
 180    Table 27.41. CLUSTER and VACUUM FULL Phases
 181    Phase Description
 182    initializing The command is preparing to begin scanning the heap. This
 183    phase is expected to be very brief.
 184    seq scanning heap The command is currently scanning the table using a
 185    sequential scan.
 186    index scanning heap CLUSTER is currently scanning the table using an
 187    index scan.
 188    sorting tuples CLUSTER is currently sorting tuples.
 189    writing new heap CLUSTER is currently writing the new heap.
 190    swapping relation files The command is currently swapping newly-built
 191    files into place.
 192    rebuilding index The command is currently rebuilding an index.
 193    performing final cleanup The command is performing final cleanup. When
 194    this phase is completed, CLUSTER or VACUUM FULL will end.
 195
 196 27.4.3. COPY Progress Reporting #
 197
 198    Whenever COPY is running, the pg_stat_progress_copy view will contain
 199    one row for each backend that is currently running a COPY command. The
 200    table below describes the information that will be reported and
 201    provides information about how to interpret it.
 202
 203    Table 27.42. pg_stat_progress_copy View
 204
 205    Column Type
 206
 207    Description
 208
 209    pid integer
 210
 211    Process ID of backend.
 212
 213    datid oid
 214
 215    OID of the database to which this backend is connected.
 216
 217    datname name
 218
 219    Name of the database to which this backend is connected.
 220
 221    relid oid
 222
 223    OID of the table on which the COPY command is executed. It is set to 0
 224    if copying from a SELECT query.
 225
 226    command text
 227
 228    The command that is running: COPY FROM, or COPY TO.
 229
 230    type text
 231
 232    The I/O type that the data is read from or written to: FILE, PROGRAM,
 233    PIPE (for COPY FROM STDIN and COPY TO STDOUT), or CALLBACK (used for
 234    example during the initial table synchronization in logical
 235    replication).
 236
 237    bytes_processed bigint
 238
 239    Number of bytes already processed by COPY command.
 240
 241    bytes_total bigint
 242
 243    Size of source file for COPY FROM command in bytes. It is set to 0 if
 244    not available.
 245
 246    tuples_processed bigint
 247
 248    Number of tuples already processed by COPY command.
 249
 250    tuples_excluded bigint
 251
 252    Number of tuples not processed because they were excluded by the WHERE
 253    clause of the COPY command.
 254
 255    tuples_skipped bigint
 256
 257    Number of tuples skipped because they contain malformed data. This
 258    counter only advances when a value other than stop is specified to the
 259    ON_ERROR option.
 260
 261 27.4.4. CREATE INDEX Progress Reporting #
 262
 263    Whenever CREATE INDEX or REINDEX is running, the
 264    pg_stat_progress_create_index view will contain one row for each
 265    backend that is currently creating indexes. The tables below describe
 266    the information that will be reported and provide information about how
 267    to interpret it.
 268
 269    Table 27.43. pg_stat_progress_create_index View
 270
 271    Column Type
 272
 273    Description
 274
 275    pid integer
 276
 277    Process ID of the backend creating indexes.
 278
 279    datid oid
 280
 281    OID of the database to which this backend is connected.
 282
 283    datname name
 284
 285    Name of the database to which this backend is connected.
 286
 287    relid oid
 288
 289    OID of the table on which the index is being created.
 290
 291    index_relid oid
 292
 293    OID of the index being created or reindexed. During a non-concurrent
 294    CREATE INDEX, this is 0.
 295
 296    command text
 297
 298    Specific command type: CREATE INDEX, CREATE INDEX CONCURRENTLY,
 299    REINDEX, or REINDEX CONCURRENTLY.
 300
 301    phase text
 302
 303    Current processing phase of index creation. See Table 27.44.
 304
 305    lockers_total bigint
 306
 307    Total number of lockers to wait for, when applicable.
 308
 309    lockers_done bigint
 310
 311    Number of lockers already waited for.
 312
 313    current_locker_pid bigint
 314
 315    Process ID of the locker currently being waited for.
 316
 317    blocks_total bigint
 318
 319    Total number of blocks to be processed in the current phase.
 320
 321    blocks_done bigint
 322
 323    Number of blocks already processed in the current phase.
 324
 325    tuples_total bigint
 326
 327    Total number of tuples to be processed in the current phase.
 328
 329    tuples_done bigint
 330
 331    Number of tuples already processed in the current phase.
 332
 333    partitions_total bigint
 334
 335    Total number of partitions on which the index is to be created or
 336    attached, including both direct and indirect partitions. 0 during a
 337    REINDEX, or when the index is not partitioned.
 338
 339    partitions_done bigint
 340
 341    Number of partitions on which the index has already been created or
 342    attached, including both direct and indirect partitions. 0 during a
 343    REINDEX, or when the index is not partitioned.
 344
 345    Table 27.44. CREATE INDEX Phases
 346    Phase Description
 347    initializing CREATE INDEX or REINDEX is preparing to create the index.
 348    This phase is expected to be very brief.
 349    waiting for writers before build CREATE INDEX CONCURRENTLY or REINDEX
 350    CONCURRENTLY is waiting for transactions with write locks that can
 351    potentially see the table to finish. This phase is skipped when not in
 352    concurrent mode. Columns lockers_total, lockers_done and
 353    current_locker_pid contain the progress information for this phase.
 354    building index The index is being built by the access method-specific
 355    code. In this phase, access methods that support progress reporting
 356    fill in their own progress data, and the subphase is indicated in this
 357    column. Typically, blocks_total and blocks_done will contain progress
 358    data, as well as potentially tuples_total and tuples_done.
 359    waiting for writers before validation CREATE INDEX CONCURRENTLY or
 360    REINDEX CONCURRENTLY is waiting for transactions with write locks that
 361    can potentially write into the table to finish. This phase is skipped
 362    when not in concurrent mode. Columns lockers_total, lockers_done and
 363    current_locker_pid contain the progress information for this phase.
 364    index validation: scanning index CREATE INDEX CONCURRENTLY is scanning
 365    the index searching for tuples that need to be validated. This phase is
 366    skipped when not in concurrent mode. Columns blocks_total (set to the
 367    total size of the index) and blocks_done contain the progress
 368    information for this phase.
 369    index validation: sorting tuples CREATE INDEX CONCURRENTLY is sorting
 370    the output of the index scanning phase.
 371    index validation: scanning table CREATE INDEX CONCURRENTLY is scanning
 372    the table to validate the index tuples collected in the previous two
 373    phases. This phase is skipped when not in concurrent mode. Columns
 374    blocks_total (set to the total size of the table) and blocks_done
 375    contain the progress information for this phase.
 376    waiting for old snapshots CREATE INDEX CONCURRENTLY or REINDEX
 377    CONCURRENTLY is waiting for transactions that can potentially see the
 378    table to release their snapshots. This phase is skipped when not in
 379    concurrent mode. Columns lockers_total, lockers_done and
 380    current_locker_pid contain the progress information for this phase.
 381    waiting for readers before marking dead REINDEX CONCURRENTLY is waiting
 382    for transactions with read locks on the table to finish, before marking
 383    the old index dead. This phase is skipped when not in concurrent mode.
 384    Columns lockers_total, lockers_done and current_locker_pid contain the
 385    progress information for this phase.
 386    waiting for readers before dropping REINDEX CONCURRENTLY is waiting for
 387    transactions with read locks on the table to finish, before dropping
 388    the old index. This phase is skipped when not in concurrent mode.
 389    Columns lockers_total, lockers_done and current_locker_pid contain the
 390    progress information for this phase.
 391
 392 27.4.5. VACUUM Progress Reporting #
 393
 394    Whenever VACUUM is running, the pg_stat_progress_vacuum view will
 395    contain one row for each backend (including autovacuum worker
 396    processes) that is currently vacuuming. The tables below describe the
 397    information that will be reported and provide information about how to
 398    interpret it. Progress for VACUUM FULL commands is reported via
 399    pg_stat_progress_cluster because both VACUUM FULL and CLUSTER rewrite
 400    the table, while regular VACUUM only modifies it in place. See
 401    Section 27.4.2.
 402
 403    Table 27.45. pg_stat_progress_vacuum View
 404
 405    Column Type
 406
 407    Description
 408
 409    pid integer
 410
 411    Process ID of backend.
 412
 413    datid oid
 414
 415    OID of the database to which this backend is connected.
 416
 417    datname name
 418
 419    Name of the database to which this backend is connected.
 420
 421    relid oid
 422
 423    OID of the table being vacuumed.
 424
 425    phase text
 426
 427    Current processing phase of vacuum. See Table 27.46.
 428
 429    heap_blks_total bigint
 430
 431    Total number of heap blocks in the table. This number is reported as of
 432    the beginning of the scan; blocks added later will not be (and need not
 433    be) visited by this VACUUM.
 434
 435    heap_blks_scanned bigint
 436
 437    Number of heap blocks scanned. Because the visibility map is used to
 438    optimize scans, some blocks will be skipped without inspection; skipped
 439    blocks are included in this total, so that this number will eventually
 440    become equal to heap_blks_total when the vacuum is complete. This
 441    counter only advances when the phase is scanning heap.
 442
 443    heap_blks_vacuumed bigint
 444
 445    Number of heap blocks vacuumed. Unless the table has no indexes, this
 446    counter only advances when the phase is vacuuming heap. Blocks that
 447    contain no dead tuples are skipped, so the counter may sometimes skip
 448    forward in large increments.
 449
 450    index_vacuum_count bigint
 451
 452    Number of completed index vacuum cycles.
 453
 454    max_dead_tuple_bytes bigint
 455
 456    Amount of dead tuple data that we can store before needing to perform
 457    an index vacuum cycle, based on maintenance_work_mem.
 458
 459    dead_tuple_bytes bigint
 460
 461    Amount of dead tuple data collected since the last index vacuum cycle.
 462
 463    num_dead_item_ids bigint
 464
 465    Number of dead item identifiers collected since the last index vacuum
 466    cycle.
 467
 468    indexes_total bigint
 469
 470    Total number of indexes that will be vacuumed or cleaned up. This
 471    number is reported at the beginning of the vacuuming indexes phase or
 472    the cleaning up indexes phase.
 473
 474    indexes_processed bigint
 475
 476    Number of indexes processed. This counter only advances when the phase
 477    is vacuuming indexes or cleaning up indexes.
 478
 479    delay_time double precision
 480
 481    Total time spent sleeping due to cost-based delay (see
 482    Section 19.10.2), in milliseconds (if track_cost_delay_timing is
 483    enabled, otherwise zero). This includes the time that any associated
 484    parallel workers have slept. However, parallel workers report their
 485    sleep time no more frequently than once per second, so the reported
 486    value may be slightly stale.
 487
 488    Table 27.46. VACUUM Phases
 489    Phase Description
 490    initializing VACUUM is preparing to begin scanning the heap. This phase
 491    is expected to be very brief.
 492    scanning heap VACUUM is currently scanning the heap. It will prune and
 493    defragment each page if required, and possibly perform freezing
 494    activity. The heap_blks_scanned column can be used to monitor the
 495    progress of the scan.
 496    vacuuming indexes VACUUM is currently vacuuming the indexes. If a table
 497    has any indexes, this will happen at least once per vacuum, after the
 498    heap has been completely scanned. It may happen multiple times per
 499    vacuum if maintenance_work_mem (or, in the case of autovacuum,
 500    autovacuum_work_mem if set) is insufficient to store the number of dead
 501    tuples found.
 502    vacuuming heap VACUUM is currently vacuuming the heap. Vacuuming the
 503    heap is distinct from scanning the heap, and occurs after each instance
 504    of vacuuming indexes. If heap_blks_scanned is less than
 505    heap_blks_total, the system will return to scanning the heap after this
 506    phase is completed; otherwise, it will begin cleaning up indexes after
 507    this phase is completed.
 508    cleaning up indexes VACUUM is currently cleaning up indexes. This
 509    occurs after the heap has been completely scanned and all vacuuming of
 510    the indexes and the heap has been completed.
 511    truncating heap VACUUM is currently truncating the heap so as to return
 512    empty pages at the end of the relation to the operating system. This
 513    occurs after cleaning up indexes.
 514    performing final cleanup VACUUM is performing final cleanup. During
 515    this phase, VACUUM will vacuum the free space map, update statistics in
 516    pg_class, and report statistics to the cumulative statistics system.
 517    When this phase is completed, VACUUM will end.
 518
 519 27.4.6. Base Backup Progress Reporting #
 520
 521    Whenever an application like pg_basebackup is taking a base backup, the
 522    pg_stat_progress_basebackup view will contain a row for each WAL sender
 523    process that is currently running the BASE_BACKUP replication command
 524    and streaming the backup. The tables below describe the information
 525    that will be reported and provide information about how to interpret
 526    it.
 527
 528    Table 27.47. pg_stat_progress_basebackup View
 529
 530    Column Type
 531
 532    Description
 533
 534    pid integer
 535
 536    Process ID of a WAL sender process.
 537
 538    phase text
 539
 540    Current processing phase. See Table 27.48.
 541
 542    backup_total bigint
 543
 544    Total amount of data that will be streamed. This is estimated and
 545    reported as of the beginning of streaming database files phase. Note
 546    that this is only an approximation since the database may change during
 547    streaming database files phase and WAL log may be included in the
 548    backup later. This is always the same value as backup_streamed once the
 549    amount of data streamed exceeds the estimated total size. If the
 550    estimation is disabled in pg_basebackup (i.e., --no-estimate-size
 551    option is specified), this is NULL.
 552
 553    backup_streamed bigint
 554
 555    Amount of data streamed. This counter only advances when the phase is
 556    streaming database files or transferring wal files.
 557
 558    tablespaces_total bigint
 559
 560    Total number of tablespaces that will be streamed.
 561
 562    tablespaces_streamed bigint
 563
 564    Number of tablespaces streamed. This counter only advances when the
 565    phase is streaming database files.
 566
 567    Table 27.48. Base Backup Phases
 568    Phase Description
 569    initializing The WAL sender process is preparing to begin the backup.
 570    This phase is expected to be very brief.
 571    waiting for checkpoint to finish The WAL sender process is currently
 572    performing pg_backup_start to prepare to take a base backup, and
 573    waiting for the start-of-backup checkpoint to finish.
 574    estimating backup size The WAL sender process is currently estimating
 575    the total amount of database files that will be streamed as a base
 576    backup.
 577    streaming database files The WAL sender process is currently streaming
 578    database files as a base backup.
 579    waiting for wal archiving to finish The WAL sender process is currently
 580    performing pg_backup_stop to finish the backup, and waiting for all the
 581    WAL files required for the base backup to be successfully archived. If
 582    either --wal-method=none or --wal-method=stream is specified in
 583    pg_basebackup, the backup will end when this phase is completed.
 584    transferring wal files The WAL sender process is currently transferring
 585    all WAL logs generated during the backup. This phase occurs after
 586    waiting for wal archiving to finish phase if --wal-method=fetch is
 587    specified in pg_basebackup. The backup will end when this phase is
 588    completed.