Marko Kreen wrote:
> When pooling connections where prepared statements are in use,
> it is hard to give new client totally clean connection as
> there may be allocated statements that give errors when
> new client starts preparing statements again.

I agree with the other comments that RESET SESSION is the right API for
this, although we can also provide DEALLOCATE ALL, I suppose.

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.

-Neil


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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?

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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.

--
marko

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 3/30/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> 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.

Yes, callback function is needed, either in HASHCTL or as
argument to deep_free().

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

I think the issue is here that its very common thing to do,
so open-coding it everywhere is waste, there should be some
utility function for that.

void hash_foreach(HTAB, void (*cb_func)(void *));

--
marko

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Marko Kreen escribió:
> On 3/30/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:

> >In any case it's not likely that there are going to be thousands of
> >prepared statements, so is this really an issue?
>
> I think the issue is here that its very common thing to do,
> so open-coding it everywhere is waste, there should be some
> utility function for that.
>
> void hash_foreach(HTAB, void (*cb_func)(void *));

Extra points if you can implement a map() function for hashes ;-) (I
think it's called "mutator" in our sources for other kind of stuff)

I think it would be
void *hash_map(HTAB, void *(*map_func) (void *))

Not sure what the return value would be though :-( (Maybe this is
extra complication enough that it's not worth the hassle)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Alvaro Herrera wrote:
> Marko Kreen escribió:
>> On 3/30/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
>
>>> In any case it's not likely that there are going to be thousands of
>>> prepared statements, so is this really an issue?
>> I think the issue is here that its very common thing to do,
>> so open-coding it everywhere is waste, there should be some
>> utility function for that.
>>
>> void hash_foreach(HTAB, void (*cb_func)(void *));
>
> Extra points if you can implement a map() function for hashes ;-) (I
> think it's called "mutator" in our sources for other kind of stuff)
>
> I think it would be
> void *hash_map(HTAB, void *(*map_func) (void *))
>
> Not sure what the return value would be though :-( (Maybe this is
> extra complication enough that it's not worth the hassle)

hash_map and hash_foreach seem like overkill to me, looping with
hash_seq_search and doing stuff is simple enough that it doesn't really
require any additional shorthands. Besides, to use them you'd always
have to have a separate function and often a struct to pass down to the
function, so it's not really any shorter or simpler.

What would be useful is a hash_seq_remove-function that removes the
previous item returned by hash_seq_search without the overhead of
recalculating the hash value.

While reviewing ITAGAKI's dead space map patch I noticed that he also
added a hash_truncate function that removes all entries in the hash
table, but unlike hash_destroy leaves the hash table intact. His
implementation also calls hash_search(REMOVE) in a loop, which isn't the
most efficient way to do it, but clearly there's need for more ways to
empty a hash table.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend