On Mon, 2013-07-01 at 07:40 -0400, Robert Haas wrote:
> On Sun, Jun 30, 2013 at 10:07 PM, Nicholas White <n.j.white@gmail.com> wrote:
> > I've attached another iteration of the patch that fixes the multiple-window
> > bug and adds (& uses) a function to create a Bitmapset using a custom
> > allocator. I don't think there's any outstanding problems with it now.
>
> I think the right way to do this is to temporarily set the current
> memory context to winobj->winstate->partcontext while creating or
> manipulating the Bitmapset and restore it afterwards. Maybe someone
> will say that's a modularity violation, but surely this is worse...
I think we should get rid of the bitmapset entirely. For one thing, we
want to be able to support large frames, and the size of the allocation
for the bitmap is dependent on the size of the frame. It would take a
very large frame for that to matter, but conceptually, it doesn't seem
right to me.
Instead of the bitmapset, we can keep track of two offsets, and the
number of rows in between which are non-NULL. That only works with a
constant offset; but I'm not inclined to optimize for the special case
involving large frames, variable offset which always happens to be
large, and IGNORE NULLS.
Regards,Jeff Davis