[FEATURE] Provide variation of the workload(s) with unsigned_long data type

[reta]

Is your feature request related to a problem?

We've introduced unsigned_long data type support recently to OpenSearch (see please opensearch-project/OpenSearch#2083), but we don't have workloads for benchmarking it yet (those have been run manually by doing ad-hoc index mapping modifications).

What solution would you like?

Provide variation of the workload(s) with unsigned_long data type

What alternatives have you considered?

Continue with ad-hoc index mapping modifications

Do you have any additional context?

See please opensearch-project/OpenSearch#2083, opensearch-project/OpenSearch#8167

[gashutos]

@bbarani @gkamat , To add something for unsigned_long it will take some time since none of the workload has this data type right now.
But if we can add total_amount sort/range queries in nyc_taxy, that is scaled_float and could be quick to close.

[reta]

But if we can add total_amount sort/range queries in nyc_taxy, that is scaled_float and could be quick to close.

I was thinking in the same vein, but for a trip_distance, thank you @gashutos

[gashutos]

But if we can add total_amount sort/range queries in nyc_taxy, that is scaled_float and could be quick to close.

I was thinking in the same vein, but for a trip_distance, thank you @gashutos

Yea ! That works too...

[jordarlu]

Hi, @IanHoang @rishabh6788 , please have a look and if any comments ... thank you!

[IanHoang]

Apologies for the delay. @gashutos feel free to open a PR to add support for this feature in the nyc_taxis workload. Please ensure that this change is done in a separate test_procedure file, similar to how searchable_snapshot test procedure has its own file in the nyc_taxis/test_procedures/ directory

[reta]

@gashutos I will take care of it, thank you for the hints folks

[gashutos]

thanks @reta .
We need for int type as well.
#94
Raised PR for that too.