Re: DEALLOCATE ALL

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Neil Conway <neilc(at)samurai(dot)com>, PGSQL-Patches <pgsql-patches(at)postgresql(dot)org>, Andrzej Rusin <Andrzej(dot)Rusin(at)interia(dot)pl>
Subject: Re: DEALLOCATE ALL
Date: 2007-03-30 13:44:28
Message-ID: 20070330134428.GE4215@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Marko Kreen escribió:
> On 3/30/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> >Neil Conway escribió:
> >
> >> As to the implementation, calling hash_remove() in a loop seems a pretty
> >> unfortunate way to clear a hash table -- adding a hash_reset() function
> >> to the dynahash API would be cleaner and faster.
> >
> >I wonder why hash_drop cannot be used?
>
> hash_destroy()? Each element need separate destruction.

Hmm, so maybe something like hash_destroy_deep, like the List
equivalent? If it's a simple pfree() for every element this would be
simple enough. If this is the case, an even simpler idea would be to
allocate the elements in the same MemoryContext as the hash itself (or
in children thereof); then calling hash_destroy() would delete (reset?)
the context and thus all elements are freed at once as well.

If by destruction you mean something different than pfree, then maybe
hash_remove in a loop is the best solution, the other idea being passing
a function pointer to hash_destroy_deep to call on each element, which
is probably too messy an API.

In any case it's not likely that there are going to be thousands of
prepared statements, so is this really an issue?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Marko Kreen 2007-03-30 14:00:29 Re: DEALLOCATE ALL
Previous Message Marko Kreen 2007-03-30 12:59:07 RESET SESSION