Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I still don't want to introduce more checking overhead into
>> hash_seq_search, though, so what I'm now thinking about is a new
>> dynahash primitive named something like "hash_freeze", which'd mark a
>> hashtable as disallowing insertions. If the hashtable is frozen before
>> hash_seq_init then we don't add it to the central list of scans, and
>> therefore there is no cleanup to do at the end. nodeAgg can use this
>> mode since it doesn't modify its hashtable anymore after beginning its
>> readout scan.
> This plan includes having the list of hash tables that mustn't be
> expanded? And the list would be cleaned up at the end of transaction, to
> avoid leaks.
Right, all that's still the same. This is just a way to exempt certain
scans from that machinery, by allowing the caller to declare he doesn't
need to modify the hashtable anymore. AFAICS that covers our needs,
at least for the present.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
