Re: Progress report: intraquery memory recovery in executor

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Progress report: intraquery memory recovery in executor
Date: 2000-07-10 07:30:09
Message-ID: 3.0.5.32.20000710173009.0227b8a0@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 02:31 10/07/00 -0400, Tom Lane wrote:
>
>What I'm currently considering instead is to still create a per-tuple
>context for each plan node, but use it only for expression evaluation,
>ie, we switch into it on entry to ExecQual(), ExecTargetList(),
>ExecProject(), maybe a few other places. The majority of our leakage
>problems are associated with expression evaluation, so this should allow
>fixing the leakage problems. It will mean that routines associated with
>plan nodes (basically, executor/node*.c) will still need to be careful
>to avoid leaks. For the most part they are already, but I had hoped to
>make that care less necessary.
>

Is it simple for the person writing the low level routines to choose
(easily) to allocate 'temporary' memory vs. 'permanent' memory? If some
mechanism were in place for this, then the code could slowly be
migrated...at least reducing the tedium.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karel Zak 2000-07-10 07:32:37 Re: Re: [BUGS] Unnexpected results using to_number()
Previous Message Karel Zak 2000-07-10 07:11:33 Re: Per-database/schema settings