Re: DEALLOCATE ALL
От | Alvaro Herrera |
---|---|
Тема | Re: DEALLOCATE ALL |
Дата | |
Msg-id | 20070330134428.GE4215@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: DEALLOCATE ALL ("Marko Kreen" <markokr@gmail.com>) |
Ответы |
Re: DEALLOCATE ALL
|
Список | 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 по дате отправления: