Execute LogicalPlans after building for TPCH Benchmarks

[DaltonModlin]

Describe the bug
Currently, running Q15 fails when attempting to build the second (SELECT) portion of the overall query.

The error is similar to the following:

called `Result::unwrap()` on an `Err` value: Plan("'datafusion.public.revenue0' not found")
thread 'tests::run_q15' panicked at 'called `Result::unwrap()` on an `Err` value: Plan("'datafusion.public.revenue0' not found")', /home/dalto/projects/arrow-datafusion/datafusion/sql/src/planner.rs:161:31

To Reproduce
Run test run_q15 in benchmarks/src/bin/tpch.rs

Expected behavior
I expect the test to fail due to either #3266 or #3267

Additional context
The table names just before failure are:

schema table names: [
    "customer",
    "supplier",
    "region",
    "part",
    "orders",
    "nation",
    "lineitem",
    "partsupp",
]

I'm unsure of where views populate this table, if anyone else has knowledge here that would be great.

[avantgardnerio]

@kmitchener @andygrove @alamb

[kmitchener]

This is happening because of the way tpch is running the test queries. q15 is made up of 3 SQL statements. run_query() attempts to create a plan for each of them before executing them. The second statement in q15 references the revenue0 view created in the first statement (which isn't created yet), so the planning of the second statement fails.

Probably run_query() should be modified to execute the statements in turn, rather than attempting to plan all of them before beginning execution.

[DaltonModlin]

That's exactly what I was thinking looking at it last night, and I was just writing a test to confirm by splitting the query. @kmitchener good to know I'm moving in the right direction. Assuming I get a different error by splitting the query, I'll try and rewrite the testing process in tpch.rs and see if it fixes this problem.

[avantgardnerio]

Probably run_query() should be modified to execute the statements in turn, rather than attempting to plan all of them before beginning execution.

This ☝️ . AFAIK, the TPC-H queries are what they are, and we have to run them as such. This one is ensuring we support multiple queries in one command, so to be TPC-H compliant I think it has to "just work".