Re: Don't overwrite scan key in systable_beginscan() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Don't overwrite scan key in systable_beginscan()
Date
Msg-id e2469df2-d15d-4d26-9e28-24e5478cb898@eisentraut.org
Whole thread Raw
In response to Re: Don't overwrite scan key in systable_beginscan()  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Don't overwrite scan key in systable_beginscan()
List 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.




pgsql-hackers by date:

Previous
From: ro b
Date:
Subject: Re: Self contradictory examining on rel's baserestrictinfo
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Consider pipeline implicit transaction as a transaction block