From: | "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Alexandr" <AVShutko(at)mail(dot)khstu(dot)ru>, <pgsql-bugs(at)postgreSQL(dot)org>, <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Postgres bug (working with iserverd) |
Date: | 2001-05-15 04:57:12 |
Message-ID: | 006201c0dcfb$81f39460$4a79583f@sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs 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
From | Date | Subject | |
---|---|---|---|
Next Message | Paul McGarry | 2001-05-15 05:08:07 | Segfault in pgsql, Sparc Solaris 2.7, Postgresql 7.1.1 |
Previous Message | Tom Lane | 2001-05-15 02:43:12 | Re: REQ: build src/backend/postgres w/o -lncurses or -lreadline |
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2001-05-15 04:58:46 | optimiser problem |
Previous Message | Stephan Szabo | 2001-05-15 04:55:31 | Re: Updating system catalogs after a tuple deletion |