Re: Don't overwrite scan key in systable_beginscan()
От
Peter Eisentraut
Тема
Re: Don't overwrite scan key in systable_beginscan()
Дата
Msg-id
22bffe21-5fa1-4be4-a757-a49a70908356@eisentraut.org
Ответ на
Re: Don't overwrite scan key in systable_beginscan() (Justin Pryzby)
Список
Дерево обсуждения
Don't overwrite scan key in systable_beginscan() Peter Eisentraut <peter@eisentraut.org>
Re: Don't overwrite scan key in systable_beginscan() Noah Misch <noah@leadboat.com>
Re: Don't overwrite scan key in systable_beginscan() Tom Lane <tgl@sss.pgh.pa.us>
Re: Don't overwrite scan key in systable_beginscan() Peter Eisentraut <peter@eisentraut.org>
Re: Don't overwrite scan key in systable_beginscan() Peter Eisentraut <peter@eisentraut.org>
Re: Don't overwrite scan key in systable_beginscan() Justin Pryzby <pryzby@telsasoft.com>
Re: Don't overwrite scan key in systable_beginscan() Peter Eisentraut <peter@eisentraut.org>
Re: Don't overwrite scan key in systable_beginscan() Justin Pryzby <pryzby@telsasoft.com>
Re: Don't overwrite scan key in systable_beginscan() Peter Eisentraut <peter@eisentraut.org>
Re: Don't overwrite scan key in systable_beginscan() Robert Haas <robertmhaas@gmail.com>
Re: Don't overwrite scan key in systable_beginscan() Tom Lane <tgl@sss.pgh.pa.us>
On 27.11.24 16:35, Justin Pryzby wrote: > On Wed, Nov 27, 2024 at 04:33:25PM +0100, Peter Eisentraut wrote: >> 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? > > Yes -- I'd already checked. Ok, I committed a fix that inserts some pfree() calls. Thanks for the report.
В списке pgsql-hackers по дате отправления