Fix handling of filter_mask in unnest function

Author: knizhnik

vops.c

@@ -166,6 +166,7 @@ typedef struct {
     TupleDesc       desc;
 	int             n_attrs;
 	int             tile_pos;
+	uint64          filter_mask;
 	vops_tile_hdr** tiles;
 } vops_unnest_context;
 
@@ -2494,7 +2495,9 @@ Datum vops_unnest(PG_FUNCTION_ARGS)
         func_ctx->user_fctx = user_ctx;
         user_ctx->n_attrs = n_attrs;
 		user_ctx->tile_pos = 0;
-
+		user_ctx->filter_mask = filter_mask;
+		filter_mask = ~0;
+		
         for (i = 0; i < n_attrs; i++) {
 			Form_pg_attribute attr = src_desc->attrs[i];
 			vops_type tid = vops_get_type(attr->atttypid);
@@ -2521,7 +2524,8 @@ Datum vops_unnest(PG_FUNCTION_ARGS)
 	n_attrs = user_ctx->n_attrs;
 
 	for (j = user_ctx->tile_pos; j < TILE_SIZE; j++) {
-		if (filter_mask & ((uint64)1 << j)) {
+		if (user_ctx->filter_mask & ((uint64)1 << j)) 
+		{
 			for (i = 0; i < n_attrs; i++) {
 				if (user_ctx->types[i] != VOPS_LAST) {
 					vops_tile_hdr* tile = user_ctx->tiles[i];

vops.html

@@ -799,7 +799,7 @@ <h2><a name="performance">Performance evaluation</a></h2>
 Now most interesting thing: compare performance results on original table and using vector operations on VOPS projection.
 All measurements were performed at desktop with 16Gb of RAM and quad-core i7-4770 CPU @ 3.40GHz processor with enabled hyper-threading.
 Data set for benchmark was generated by dbgen utility included in TPC-H benchmark.
-Scale factor is 100 which corresponds to about 8Gb database. It can completely fit in memory,
+Scale factor is 10 which corresponds to about 8Gb database. It can completely fit in memory,
 so we are measuring best query execution time for <i>warm</i> data.
 Postgres was configured with shared buffer size equal to 8Gb.
 For each query we measured time of sequential and parallel execution with 8 parallel workers.