On Sun, May 17, 2020 at 11:40:53AM -0400, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
> > I was executing this query:
> > insert into ct_entry_chain (ct_entry_id, certificate_id) select id,
> > unnest(certificate_chain_id) from ct_entry;
>
> How much data is that?
The ct_entry table contains 305 GB data over about 2.1e9 rows.
certificate_chain_id contains about 2.2 entries per row.
> > The process was using at least 14 GB, of the 8 GB of RAM that's available.
>
> My first guess is that the space was being eaten by trigger list entries
> to verify the foreign-key constraints on the target table. You might be
> better advised to fill the new table first and then create its FK
> constraints. (Building the indexes afterwards wouldn't be a bad idea,
> either.)
>
> We are looking at better mechanisms for handling FK verification, but
> that won't see the light of day before v14 at the earliest.
I will try that, thanks.
Kurt