Add Hive and Iceberg Load benchmark

[PingLiuPing]

loading (insert) benchmark is missing in pbench, this PR add the initial files for loading benchmark. It includes test files for hive and iceberg connector, both native and Java.
The data is loaded from tpch connector on the fly.

Future enhancements are required to make the benchmark run in stage such as prepare stage, main stage, cleanup stage etc.

[PingLiuPing]

@wanglinsong @ethanyzhang Sorry for the late response, this PR slipped from my mind. I addressed your comments, can you please take another look? Thanks.

[wanglinsong]

I believe the DDL to create tables are the same across all scale factors. Can you parameterize or remove the hardcoded schema name: tpch.sf100.?

FROM tpch.sf100.customer;

[PingLiuPing]

believe the DDL to create tables are the same across all scale factors. Can you parameterize or remove the hardcoded schema name: tpch.sf100.?

FROM tpch.sf100.customer;

Thanks, at the current framework I think this needs lots of work to support that.

[wanglinsong]

believe the DDL to create tables are the same across all scale factors. Can you parameterize or remove the hardcoded schema name: tpch.sf100.?
FROM tpch.sf100.customer;

Thanks, at the current framework I think this needs lots of work to support that.

Oh, this is an embedded connector. This is not an issue at all. Please ignore.

[PingLiuPing]

Hi @wanglinsong Thanks for your comments, do you think this PR is ready to be merged? Anything else you want me to change?

[PingLiuPing]

@wanglinsong can you please have another look, thanks.

[PingLiuPing]

@wanglinsong gentle ping.

[xpengahana]

Have we tested this PR for pbench? @PingLiuPing

[PingLiuPing]

Have we tested this PR for pbench? @PingLiuPing

Thanks, I didn't test this after fix the review comments. Before that I have tested it in pbench.
So think this commit might not correct aee3644.
I will verify this.

[ethanyzhang]

Thanks for adding the TPC-H loading benchmarks! I reviewed the files and have some findings before we integrate.

Issues to fix

1. prepare_sf1000.json description typo
Says "scaling factor 100" — should be "scaling factor 1000".

2. expected_row_counts mismatch in insert stages
All 4 insert stages (insert_sf100_j.json, insert_sf100_n.json, insert_sf1000_j.json, insert_sf1000_n.json) have 10 values but only 8 query files (= 8 queries). The extra 2 values are silently ignored. Should be exactly 8.

3. expected_row_counts off-by-one in prepare stages
schema/create_sf100.sql and schema/create_sf1000.sql each contain 2 SQL statements (CREATE SCHEMA + USE), so total queries per prepare stage = 2 + 8 = 10. But expected_row_counts only has 9 values — the last CREATE TABLE won't be validated. Should be 10.

4. Column type mismatches vs TPC-H spec
These columns should be INTEGER, not BIGINT:

• lineitem.linenumber
• orders.shippriority
• part.size
• partsupp.availqty

5. DECIMAL(12,2) should be DECIMAL(15,2)
The TPC-H spec defines decimal columns with precision 15. Precision 12 could cause truncation at larger scale factors.

@PingLiuPing @xpengahana Did we generate the right schema?

Suggestions (non-blocking)

6. No IF EXISTS on DROP statements
DROP TABLE and DROP SCHEMA will fail if tables/schema don't exist (e.g. after a partial run). Consider DROP TABLE IF EXISTS / DROP SCHEMA IF EXISTS.

7. Inconsistent SQL casing
drop schema (lowercase) in schema drop files vs DROP TABLE (uppercase) everywhere else.

8. Consider abort_on_error: true
For data loading workflows, it's usually better to fail fast — if a CREATE TABLE or INSERT fails, continuing with missing tables wastes time. None of the stages set abort_on_error.