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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: optimiser problem
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: bug in pgcrypto 0.3