Re: DEALLOCATE ALL - Mailing list pgsql-patches

From Alvaro Herrera
Subject Re: DEALLOCATE ALL
Date
Msg-id 20070330134428.GE4215@alvh.no-ip.org
Whole thread Raw
In response to Re: DEALLOCATE ALL  ("Marko Kreen" <markokr@gmail.com>)
Responses Re: DEALLOCATE ALL  ("Marko Kreen" <markokr@gmail.com>)
List pgsql-patches
Marko Kreen escribió:
> On 3/30/07, Alvaro Herrera <alvherre@commandprompt.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

pgsql-patches by date:

Previous
From: "Marko Kreen"
Date:
Subject: RESET SESSION
Next
From: "Marko Kreen"
Date:
Subject: Re: DEALLOCATE ALL