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