Re: pg_dump verbose start and stop times?

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
Cc: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump verbose start and stop times?
Date: 2025-05-30 13:48:08
Message-ID: aDm3GG7Q3SPq3t21@depesz.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Fri, May 30, 2025 at 08:54:24AM -0400, Ron Johnson wrote:
> And yet it's not possible to show how long it takes to copy each object .
> This, at least, does the math to show the grand elapsed time, and puts an
> easily greppable string in the cron job's stdout+stderr log file:
>
> time_it()
> {
> local ActionLabel=$1
> shift
> date +"%n%F %T TIMEIT $ActionLabel started.%n"
> START_SECS=$(date +"%s")
> $@
> local RC=$? ; echo "TIMEIT Return Code = $RC"
> FINISH_SECS=$(date +"%s")
> ET=$(echo "scale=2;(${FINISH_SECS} - ${START_SECS})/60" | bc)
> date +"%n%F %T TIMEIT $ActionLabel finished. Elapsed time: ${ET}
> minutes."
> return $RC
> }
>
> time_it DUMP_$DB pg_dump -j ${Threads} -Z${ZLvl} -v -C -Fd --file=$DB $DB
> 2> ${DB}_pgdump.log

You do know that you could have just done:

time pg_dump …

without the time_it function?

And if you'd want to write your own function, assuming you're running
not-so-ancient bash, you could have just used $EPOCHREALTIME and not the
date +… ?

Best regards,

depesz

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Joe Tailleur 2025-05-30 13:50:47 Re: Seeking Suggestions for Best Practices: Archiving and Migrating Historical Data in PostgreSQL
Previous Message Scott Ribe 2025-05-30 13:45:41 Re: Seeking Suggestions for Best Practices: Archiving and Migrating Historical Data in PostgreSQL