| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | dgrowleyml(at)gmail(dot)com |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Material node can report incorrect "Maximum Storage" in EXPLAIN |
| Date: | 2026-10-01 06:49:12 |
| Message-ID: | 20261001.154912.471314161999238817.ishii@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 40708acd6 added code to have EXPLAIN ANALYZE show the memory or disk
> usage for Material nodes.
You mean 1eff8279d?
> This isn't quite right as if the material
> node is rescanned, tuplestore_end() is called and that will result in
> the memory usage for that scan being forgotten. What EXPLAIN reports
> is the memory used by the final Material rescan. If that's
> significantly less than some other rescan, then that's misleading.
>
> The fix is fairly simple, just use tuplestore_clear() instead of
> tuplestore_end(). The existing code seems to handle no longer
> NULLifying the tuplestore due to the tuplestore_ateof() check.
The patch looks good to me.
> The misreporting of the storage likely isn't a big deal. I suspect
> rescans of Material nodes are not massively common, so maybe it's not
> worth backpatching a fix.
I have no evidence but I feel same as you (rescans of Material nodes
are not massively common). Probably it's not worth backpatching. If we
need backpatching, we could do it later.
Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-10-01 07:04:25 | Re: pgindent to ignore build directories |
| Previous Message | Nisha Moond | 2026-10-01 06:39:25 | Re: Fix apply worker crash when subscriber table has only a deferrable primary key |