Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 07b47f1

Browse files
nathan-bossartCommitfest Bot
authored and
Commitfest Bot
committed
Skip second WriteToc() for custom-format dumps without data.
Presently, "pg_dump --format=custom" calls WriteToc() twice. The second call is intended to update the data offset information, which allegedly makes parallel pg_restore significantly faster. However, if we aren't dumping any data, this step accomplishes nothing and can be skipped. This is a preparatory optimization for follow-up commits that will move the queries for attribute statistics to WriteToc()/_printTocEntry() to save memory. Reviewed-by: Jeff Davis <pgsql@j-davis.com> Discussion: https://postgr.es/m/Z9c1rbzZegYQTOQE%40nathan
1 parent a7187c3 commit 07b47f1

File tree

1 file changed

+4
-2
lines changed

1 file changed

+4
-2
lines changed

src/bin/pg_dump/pg_backup_custom.c

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -755,9 +755,11 @@ _CloseArchive(ArchiveHandle *AH)
755755
* If possible, re-write the TOC in order to update the data offset
756756
* information. This is not essential, as pg_restore can cope in most
757757
* cases without it; but it can make pg_restore significantly faster
758-
* in some situations (especially parallel restore).
758+
* in some situations (especially parallel restore). We can skip this
759+
* step if we're not dumping any data; there are no offsets to update
760+
* in that case.
759761
*/
760-
if (ctx->hasSeek &&
762+
if (ctx->hasSeek && AH->public.dopt->dumpData &&
761763
fseeko(AH->FH, tpos, SEEK_SET) == 0)
762764
WriteToc(AH);
763765
}

0 commit comments

Comments
 (0)