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
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 |