Re: Limit memory usage by postgres_fdw batches

From: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Limit memory usage by postgres_fdw batches
Date: 2026-01-13 10:44:48
Message-ID: f4001f334060ea68053be6940415cc6f@postgrespro.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi.

I've looked at the third patch more and found some evident issues.
1) While using tuplestore we get too much garbage from tuple conversion,
which was not cleared properly. Tried to fix it, but now we come to the
second problem.

2) While receiving tuples we've already allocated memory in libpq, so it
can be too late to do something. In simple examples I can see libpq
result sets which have several GB size (and likely are not limited by
anything).

I've used the attached script to create some tables.

select create_partitioned_rel('t1', 128, true, 1);
select create_partitioned_rel('t2', 4, true, 100);

insert into t1 select i, pg_read_binary_file('/some/100mb/file') from
generate_series(1,128) i;
insert into t2 select i, pg_read_binary_file('/some/100mb/file') from
generate_series(1,128) i;

And with simple queries like

select sum(length(s)) from TABLE;

we can see that backend can easily consume up to several GBs of RAM.

For now I start thinking we need some form of FETCH, which stops
fetching data based on batch size...
--
Best regards,
Alexander Pyhalov,
Postgres Professional

Attachment Content-Type Size
create_test_example.sql text/plain 2.0 KB
v3-0001-Limit-batch_size-for-foreign-insert-with-work_mem.patch text/x-diff 2.7 KB
v3-0002-Fall-back-to-foreign-insert-when-tuple-is-too-big.patch text/x-diff 10.2 KB
v3-0003-WIP-Use-tuplestore-in-PgFdwScanState-scan-state-to-l.patch text/x-diff 6.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nitin Motiani 2026-01-13 10:50:44 Re: Adding pg_dump flag for parallel export to pipes
Previous Message Dilip Kumar 2026-01-13 10:39:30 Re: Proposal: Conflict log history table for Logical Replication