Re: BUG #16443: Too much memory usage on insert query

From: Kurt Roeckx <kurt(at)roeckx(dot)be>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16443: Too much memory usage on insert query
Date: 2020-05-17 16:01:50
Message-ID: 20200517160150.GJ2915@roeckx.be
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, May 17, 2020 at 11:40:53AM -0400, Tom Lane wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2020-05-18 07:35:43 BUG #16446: ERROR: virtual tuple table slot does not have system attributes on insert to partitioned table
Previous Message Tom Lane 2020-05-17 15:40:53 Re: BUG #16443: Too much memory usage on insert query