| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Sergei Kornilov <sk(at)zsrv(dot)org>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
| Subject: | Re: [HACKERS] generated columns |
| Date: | 2019-01-17 01:12:26 |
| Message-ID: | 20190117011226.GB2036@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 16, 2019 at 02:14:41PM +0100, Peter Eisentraut wrote:
> On 15/01/2019 08:13, Michael Paquier wrote:
>> When testing a bulk INSERT into a table which has a stored generated
>> column, memory keeps growing in size linearly, which does not seem
>> normal to me. If inserting more tuples than what I tested (I stopped
>> at 10M because of lack of time), it seems to me that this could result
>> in OOMs. I would have expected the memory usage to be steady.
>
> What are you executing exactly? One INSERT command with many rows?
Yes, something like that grows the memory and CPU usage rather
linearly:
CREATE TABLE tab (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
INSERT INTO tab VALUES (generate_series(1,100000000));
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-01-17 01:16:38 | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
| Previous Message | Michael Paquier | 2019-01-17 00:54:16 | Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name |