Re: [BUGS] Postgres bug (working with iserverd)
От | Vadim Mikheev |
---|---|
Тема | Re: [BUGS] Postgres bug (working with iserverd) |
Дата | |
Msg-id | 006201c0dcfb$81f39460$4a79583f@sectorbase.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Postgres bug (working with iserverd) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Postgres bug (working with iserverd)
|
Список | pgsql-hackers |
> However, EvalPlanQual still leaks more memory than suits me --- > auxiliary memory allocated by the plan nodes is not recovered. > I think the correct way to implement it would be to create a new > memory context for each level of EvalPlanQual execution and use > that context as the "per-query context" for the sub-query. The > whole context (including the copied plan) would be freed at the > end of the sub-query. The notion of a stack of currently-unused > epqstate nodes would go away. > > This would mean a few more cycles per tuple to copy the plan tree over > again each time, but I think that's pretty trivial compared to the plan > startup/shutdown costs that we incur anyway. Besides, I have hopes of > making plan trees read-only whenever we do the fabled querytree > redesign, so the cost will someday go away. Isn't plan shutdown supposed to free memory? How subselects run queries again and again? I wasn't in planner/executor areas for long time and have no time to look there now -:(, so - just asking -:) Vadim
В списке pgsql-hackers по дате отправления: