I've fixed the problems you mentioned (see attached) - sorry, I was a bit careless with the docs.
> + null_values = (Bitmapset *) WinGetPartitionLocalMemory( > + winobj, > + BITMAPSET_SIZE(words_needed)); > + Assert(null_values); > > This certainly seems ugly - isn't there a way to accomplish this > without having to violate the Bitmapset abstraction? Indeed, it's ugly. I've revised it slightly to: > null_values = (Bitmapset *) WinGetPartitionLocalMemory( > winobj, > BITMAPSET_SIZE(words_needed)); > null_values->nwords = (int) words_needed; ...which gives a proper bitmap. It's hard to break this into a factory method like bms_make_singleton as I'm getting the (zero'ed) partition local memory from one call, then forcing a correct bitmap's structure on it. Maybe bitmapset.h needs an bms_initialise(void *, int num_words) factory method? You'd still have to use the BITMAPSET_SIZE macro to get the correct amount of memory for the void*. Maybe the factory method could take a function pointer that would allocate memory of the given size (e.g. Bitmapset* initialize(void* (allocator)(Size_t), int num_words) ) - this means I could still use the partition's local memory. I don't think the solution would be tidier if I re-instated the leadlag_context struct with a single Bitmapset member. Other Bitmapset usage seems to just call bms_make_singleton then bms_add_member over and over again - which afaict will call palloc every BITS_PER_BITMAPWORD calls, which is not really what I want. Thanks - Nick
lead-lag-ignore-nulls.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
