Re: Reducing memory usage of insert into select operations?

From: Richard Huxton <dev(at)archonet(dot)com>
To: lists(at)stringsutils(dot)com
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Reducing memory usage of insert into select operations?
Date: 2008-07-18 15:25:57
Message-ID: 4880B605.90404@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Francisco Reyes wrote:
> On 8:13 am 07/18/08 Richard Huxton <dev(at)archonet(dot)com> wrote:
>> Is the partition split done with triggers or rules?
>
> I have a single trigger+function combo that dynamically computes which
> partition the data has to go to.

I'm wondering whether it's memory usage either for the trigger itself,
or for the function (pl/pgsql?). If you're doing something like:
INSERT INTO partitioned_table SELECT * FROM big_table
then that's not only taking place within a single transaction, but
within a single statement.

Without being a hacker, I'd say it's entirely plausible that PG might
clean up triggers at the end of a statement meaning you would need
memory for 200million+ triggers.

Alternatively, it could be a memory-leak somewhere in the pl/pgsql or
trigger code. Wouldn't have to be much to affect this particular case.

What happens if you do the insert/select in stages but all in one
transaction? Do you see PG's memory requirement stay constant or grow in
steps. That will show whether the memory is growing over the duration of
a statement or a transaction.

BEGIN;
INSERT ... SELECT ... WHERE id BETWEEN 0 AND 999999
INSERT ... SELECT ... WHERE id BETWEEN 1000000 AND 1999999
...
COMMIT;

--
Richard Huxton
Archonet Ltd

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Francisco Reyes 2008-07-18 15:50:43 Re: Reducing memory usage of insert into select operations?
Previous Message Tom Lane 2008-07-18 15:01:23 Re: Initdb problem on debian mips cobalt: Bus error