Re: [PATCH] Add memory/disk usage for Function Scan nodes in EXPLAIN

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add memory/disk usage for Function Scan nodes in EXPLAIN
Date: 2026-10-07 01:14:13
Message-ID: CAApHDvpbGg1uH6SqmyjtJO8f_rT1pj903sVjGmEG_ReKmAtLNA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 6 Oct 2026 at 03:09, Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com> wrote:
> > 1. I'm confused by the following in explain.sql. We don't support
> > parallel function scans, so the comments and setting of
> > max_parallel_workers_per_gather seem bogus:
>
> Function Scan isn't parallel-aware, but generate_series() is parallel
> safe, so with debug_parallel_query = regress the whole plan runs in a
> parallel worker. EXPLAIN only reads the storage information from the
> leader's tuplestore, so the Storage line doesn't appear in that case.
>
> Indeed, when I removed the setting and ran make check with
> debug_parallel_query = regress, the Storage line disappeared from all
> three of the new tests and the explain test failed.
>
> So I kept the setting and rewrote the comment to make the reason
> clearer.

That doesn't seem great. On checking, I see Material has the same
issue, but that's not been highlighted by the buildfarm members
running debug_parallel_query = regress due to lack of EXPLAIN ANALYZE
test that has a Material node. I've just posted a patch to fix that in
[1]. Can you follow that code and resolve this issue in your patch?

David

[1] https://postgr.es/m/CAApHDvoUWCms-b27MpDKd5_RUFtAnVrxPgN9u3QoQbBihk+S6g@mail.gmail.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-10-07 01:17:59 Re: [PG19] eager aggregation gives wrong results because of bpchar_ops
Previous Message David Rowley 2026-10-07 01:11:34 Material node doesn't show "Maximum Storage" for parallel workers