Re: Confirming pg_repack being successful - Mailing list pgsql-admin
| From | Keith Fiske |
|---|---|
| Subject | Re: Confirming pg_repack being successful |
| Date | |
| Msg-id | CAODZiv5LD3tNAHhyt7AH0o2pzLp5Q8rw2-yJbiEN1QFb4yUzVw@mail.gmail.com Whole thread Raw |
| In response to | Confirming pg_repack being successful (Wells Oliver <wells.oliver@gmail.com>) |
| List | pgsql-admin |
On Thu, May 9, 2024 at 7:14 PM Wells Oliver <wells.oliver@gmail.com> wrote:
Is there something definitive one can do to confirm the success of pg_repack? It's my first real usage of it, and I did -E DEBUG, and the final output lines look like so:NOTICE: Waiting for 1 transactions to finish. First PID: 13560
NOTICE: Waiting for 1 transactions to finish. First PID: 13560
DEBUG: ---- swap ----
DEBUG: query failed: ERROR: canceling statement due to statement timeout
DETAIL: query was: LOCK TABLE stats.pitches IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR: canceling statement due to statement timeout
DETAIL: query was: LOCK TABLE stats.pitches IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR: canceling statement due to statement timeout
DETAIL: query was: LOCK TABLE stats.pitches IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR: canceling statement due to statement timeout
DETAIL: query was: LOCK TABLE stats.pitches IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR: canceling statement due to statement timeout
DETAIL: query was: LOCK TABLE stats.pitches IN ACCESS EXCLUSIVE MODE
DEBUG: query failed: ERROR: canceling statement due to statement timeout
DETAIL: query was: LOCK TABLE stats.pitches IN ACCESS EXCLUSIVE MODE
DEBUG: ---- drop ----
DEBUG: ---- analyze ----
DEBUG: Disconnecting worker 0.
DEBUG: Disconnecting worker 1.
DEBUG: Disconnecting worker 2.
DEBUG: Disconnecting worker 3.
DEBUG: Disconnecting worker 4.
DEBUG: Disconnecting worker 5.
DEBUG: Disconnecting worker 6.
DEBUG: Disconnecting worker 7.I... think it worked, the n_dead_tup number is lower, which is what I was expecting. I just wondered if there might be something definitive here.Thanks.--Wells Oliver
wells.oliver@gmail.com
Normal vacuums should be taking care of n_dead_tuple. If they're not, pg_repack isn't going to help with that either because it means a transaction is open and holding them. What repack more typically helps with is recovering free, re-usable space that cleaning up the dead tuples leaves behind. To tell if that's been successful a simple comparison of the table size before and after is the easiest thing to check. Or you can use the "pgstattuple" contrib module to see the free space.
Note that you'd have to check each individual index as well as any TOAST tables to get a full picture of the free space cleanup. I wrote a tool that uses pgstattuple but fully scans the given table(s) and gives easier to read output.
pgsql-admin by date: