[Monetdb-developers] GDKupgradevarheap allocate/copy inconsistency

Sjoerd Mullender sjoerd at acm.org
Fri Jan 22 09:37:33 CET 2010


On 2010-01-21 23:06, Isidor Zeuner wrote:
> Dear MonetDB developers,
> 
> please see the newly created tracker item [1].
> 
> I haven't seen relevant design documentation which would have
> allowed me to deduce if BATs from VIEWcreate_ are actually supposed to
> end up in GDKupgradevarheap, as it happened to me. Still, I could
> imagine the suggested fix to be a step in the right direction as it
> helps modularity by making the function working with less
> preassumptions on the inputs. However, if it fits into the global
> design, the capacity argument can (should?) be removed from the
> function signature.
> 
> Best regards,
> 
> Isidor Zeuner
> 
> [1] https://sourceforge.net/tracker/?func=detail&aid=2936616&group_id=56967&atid=482468

I saw the tracker item, and was wondering about it.

What did you do to get into the situation?  In other words, how can I
reproduce?

I don't think BATs created in VIEWcreate_ should end up in
GDKupgradevarheap.  Those BATs are views, and I would think views are
read-only, and read-only BATs should not end up here.

The BAT capacity is the number of elements that can be stored in the
BAT, i.e. it is exactly the size of the heap (apart from the
multiplication with the width of the elements).  However, this may break
down in the case of views.  When I wrote the code, I wasn't thinking of
views, since I didn't expect them to end up here, and I still think they
shouldn't.

Having said this, it is probably possible, perhaps even equivalent, to
use the size as you suggested instead of the capacity -- as long as
views are left out of the equation.

So I would really like to see how views end up being upgraded.

-- 
Sjoerd Mullender




More information about the developers-list mailing list