Re: Add a property to automatically suspend portals as they produce given number of bytes

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add a property to automatically suspend portals as they produce given number of bytes
Date: 2025-12-07 10:25:08
Message-ID: CALdSSPjXk+NZs0sZq2F89nxaaSntZj2nrjMu7LjA1o2-j4f29g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 17 Jan 2025, 17:22 Vladimir Sitnikov, <sitnikov(dot)vladimir(at)gmail(dot)com>
wrote:

> Kirill,
>
> cursor does not provide a way to limit the fetch size based on the memory
> consumption.
> Imagine a table like (id int8, value jsonb).
> If we use "fetch 1000", then it might require 1GiB on the client if every
> row contains 1MiB json.
> If the client plays defensively and goes for "fetch 10", it might take a
> lot of time if jsons are small.
>
> Neither cursor nor extended protocol solve the problem.
>
> Vladimir
>

Hi!
Thank you for explaining this. I think you can propose your patch now,
because I don't see any major show-stopper right now.

The only issue is that this would be a PostreSQL extension, which will
impose extra maintenance pain to kernel hackers.

Also, note that we do not know individual row size in advance, because
tuples attributes may be toasted. So, your query will return first time it
tries to allocate more than $limit bytes, not before. Or, at least,
straightforward implementation of this feature would.

Best regards,
Kirill Reshke

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-12-07 11:21:47 Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Previous Message cca5507 2025-12-07 08:34:29 Re: Fix incorrect comments in tuplesort.c