Skip to content

collect table statistics before renaming table #1418

Open

Description

@wangzihuacool

I encountered an extreme case last week. After alter table using gh-ost, the table statistics was not updated until half an hour later, causing a lot of slow queries.
The root cause of this issue is that the statistical event for this table was lost while being placed in the asynchronous queue waiting waiting to be consumed by background statistics update thread.

This may be an extreme case, but since the collection of statististics is performed asynchronously in the background, it is very likely that there will be situations where the statistics are not updated for a period of time after gh-ost modification, especially when there are a large number of tables in the database.

I wrote a script to test gh-ost schema changes thousands of times, and it often happens that the table's statistics were updated 2-3 seconds after gh-ost renames the table. I'm thinking if gh-ost could collect statistics once before renaming table, in order to avoid the issue of statistics not being updated in time after the schema change.

part of test info below:

                              table_name: sbtest1

    table_stats_last_update_time: 2024-05-19 02:07:06

    table_stats_last_update_rows: 134208

        gh_ost_table_create_time: 2024-05-19 10:47:47

        gh_ost_table_rename_time: 2024-05-19 10:47:56

              gh_ost_finish_time: 2024-05-19 10:47:47

  table_stats_after_gh_ost_finish_rows: 0

   table_stats_final_update_time: 2024-05-19 10:47:58

          table_stats_final_rows: 134208`

Activity

  1. VandhanaSelvaprakash-at commented on Jul 29, 2026

    @VandhanaSelvaprakash-at
    Contributor

    Hi, following up on this, since we've hit this exact issue at Airtable, and have deployed a fix in our fork.

    Our version adds the opt-in flag (--analyze-ghost-table-before-cutover, default off) and the docs, and addresses two things we hit in practice:

    • it runs the ANALYZE after the cut-over postpone gate releases, so a postponed cut-over doesn't re-stale its statistics before the swap
    • a failed ANALYZE aborts the migration (fatal) rather than swapping in a table with stale stats — ANALYZE TABLE surfaces table-level failures as Msg_type=Error rows while the statement itself succeeds, so we inspect the result rows and fail closed.
    • It's flag-gated, so the partition-count/replication-lag concern @shaohk raised only applies to opt-in users.

    Happy to open a PR that supersedes this one and credits @wangzihuacool as the original author — @timvaillancourt does that work for you?

  2. ericyan commented on Aug 4, 2026

    @ericyan
    Contributor

    Hi @VandhanaSelvaprakash-at , please feel to open a new PR (with credits to @wangzihuacool) for this 👍

  3. VandhanaSelvaprakash-at commented on Aug 5, 2026

    @VandhanaSelvaprakash-at
    Contributor

    Thanks Eric, opened PR #1747 as discussed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions