Re: [HACKERS] Advice wanted on backend memory management

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Advice wanted on backend memory management
Date: 1999-05-05 01:18:13
Message-ID: 372F9C55.C0BADB02@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> I want to change hashjoin's use of a fixed-size overflow area for tuples
> that don't fit into the hashbucket they ought to go in. Since it's
> always possible for an improbably large number of tuples to hash into the
> same hashbucket, the overflow area itself can overflow; without the
> ability to recover from that, hashjoin is inherently unreliable.
> So I think this is an important thing to fix.
>
> To do this, I need to be able to allocate chunks of space that I will
> later want to give back all at once (at the end of a hash pass).
> Seems to me like a job for palloc and a special memory context ---
> but I see no way in mcxt.h to create a new memory context. How do
> I do that? Also, I'd want the new context to be a "sub-context" of

No way :(
StartPortalAllocMode could help but - portalmem.c:
/*
* StartPortalAllocMode
* Starts a new block of portal heap allocation using mode and limit;
* the current block is disabled until EndPortalAllocMode is called.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm unhappy with this allocation block stacking for quite long time :(

Try to pfree chunks "by hand".

Vadim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 1999-05-05 01:33:08 || in v6.4.2 ...
Previous Message Christian 1999-05-05 00:23:02 6.4.2 core dumping.