Should pg_restore vacuum the tables before the post-data stage?

From: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Should pg_restore vacuum the tables before the post-data stage?
Date: 2022-02-08 10:21:25
Message-ID: c1d62e8d-2bca-5326-ed23-a78c32d08fea@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

I was wondering if pg_restore should call VACUUM ANALYZE for all tables,
after the "COPY" stage, and before the "post-data" stage.

Indeed, without such a VACUUM, the visibility map isn't available.
Depending on the size of the tables and on the configuration, a foreign
key constraint check would have to perform either:

* a seq scan of the referencing table, even if an index exists for it;
* a index-only scan, with 100% of heap fetches.

And it's the same for the referenced table, of course, excepts the index
always exists.

In both cases, it could be very slow.

What's more, the seq scan isn't parallelized [1].

It seems to me that in most cases, autovacuum doesn't have enough time
to process the tables before the post-data stage, or only some of them.

What do you think?

If the matter has already been discussed previously, can you point me to
the thread discussing it?

Best regards,
Frédéric

[1]
https://www.postgresql.org/message-id/flat/0d21e3b4-dcde-290c-875e-6ed5013e8e52%40dalibo.com

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-02-08 11:14:02 Re: Database-level collation version tracking
Previous Message Amit Kapila 2022-02-08 09:51:19 Re: [BUG]Update Toast data failure in logical replication