Hi Roberto,
I wrote:
X_3:bat[:oid,:lng] =<tmp_321264>[0] := bat.new(nil:oid,nil:lng); .. # X_3 is never used before this line. X_19=<tmp_331015>[23068647] := <some computation> X_20=<tmp_321264>[23068647] := bat.append(X_3=<tmp_321264>:bat[:oid,:lng][23068647], X_19=<tmp_331015>[23068647],true); # X_3 is never used after this line.
Roberto Cornacchia roberto.cornacchia@gmail.com writes:
Unless I misunderstand the problem, I think you can't just use X_3 because that is the bat that corresponds to the physical column of your table a. So you can't take it and append b to it. Union creates a copy of a, then appends b, then c.
Thanks for your reply.
No, here X_3 is a new BAT (it is the result of bat.new).
The BAT from a physical column come from call to sql.bind.
But I'm new to MonetDB, so I might be missing some details too.
The value between brackets ([]) indicate the number of rows after the call, and we can see that at first X_3 is empty (as expected), that X_19 contains a lot of rows (23M). And then this one is concatened to the empty one. As a result of bat.append, we get the same BAT referenced by X_3 (we see its internal name between <> as temp_321264), not some another BAT created by the call itself.
Moreover, what I didn't specify, but was implied in my original post, is that X_19 is no longer used after the call to bat.append. We see that X_3 become of copy of X_19, and it replaces it entirely. This is damageable for the performance.