| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Don't overwrite scan key in systable_beginscan() |
| Date: | 2024-11-27 15:33:25 |
| Message-ID: | e2469df2-d15d-4d26-9e28-24e5478cb898@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 26.11.24 14:56, Justin Pryzby wrote:
> Since 811af9786b, the palloc'd idxkey's seem to be leaking/accumulating
> throughout the command.
>
> I noticed this on the master branch while running ANALYZE on partitioned
> table with 600 attributes, even though only 6 were being analyzed.
>
> LOG: level: 3; BuildRelationExtStatistics: 1239963512 total in 278 blocks; 5082984 free (296 chunks); 1234880528 used
>
> Several indexes are being scanned many thousands of times.
Hmm, this patch inserts one additional palloc() call per
systable_beginscan(). So it won't have much of an impact for isolated
calls, but for thousands of scans you get thousands of small chunks of
memory.
Does your test case get better if you insert corresponding pfree() calls?
A higher-level question would be whether there should be better memory
management in the caller. But it would be okay to address it with a
pfree() as well, I think.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2024-11-27 15:35:09 | Re: Consider pipeline implicit transaction as a transaction block |
| Previous Message | ro b | 2024-11-27 15:28:17 | Re: Self contradictory examining on rel's baserestrictinfo |