Modify Default StorageBlockLayout

[cramja]

User should be able to modify the default StorageBlockLayout of temporary relations.

This could be specified by a gflag or a \command.

If this were a permanent feature that a user could benefit from, it would make sense as a command. Otherwise, if it is temporary and might one day be automatically determined, then it would probably make more sense as a flag.

For example, if it was a gflag, it might look like:
./quickstep_cli_shell --default_blockproperties="{type:columnstore, blocksize:100}"

[zuyu]

You should check out #31.

[pateljm]

@cramja I love the part about automatically determined as that is in line with our aspiration to be free of tuning parameters! Sounds like in most cases, with a simple cost model, we should be able to pick the right block format. Will need to feed off your current study for block properties.

[cramja]

@pateljm On it. This morning I'm seeing if we can't work out the kinks in SplitRow insertion optimization. If we can, then it's a pretty safe bet that Packed/Split stores are the best choice intermediate block for a query with a single intermediate block insertion (SELECT * FROM foo WHERE foo.a LIKE "%bar%").

It's not obvious to me what the rationale would be for more complex pipelines.

[cramja]

I mocked up this branch to do some simple benchmarks over a 6gb (scale 10) LineOrder table from SSB. It showed that the current default is actually the fastest. The current default uses RowStores (packed and split).

The reason Rowstores outperform Columnstores is likely because the ValueAccessor class is designed for row-wise inserts.

The following results are times from projecting 1 attribute (lo_orderkey).

SRC DEST
ccs columnstore 2.3684766667
ccs rowstore    0.1795503333
cs  columnstore 1.9068166667
cs  rowstore    0.1541016667
srs columnstore 2.7117933333
srs rowstore    0.877598