Add support for MaxResults on Glue Hive Metastore

[v-jizhang]

Cherry pick of trinodb/trino#3024 and
trinodb/trino#4938

Co-authored-by: Istvan [email protected]
Co-authored-by: Ashhar Hasan [email protected]

== RELEASE NOTES ==

Hive Changes
* Add support for MaxResults on Glue Hive Metastore

[aweisberg]

Hard coded values gives me slight pause, but it's in production in Trino and no one is complaining so I will +1 it.

This is metadata so I assume a constant metadata fetch size is acceptable although if it includes statistics it seems like it might be a value people want to change?

[aweisberg]

@pettyjamesm do you have an opinion on this being hard coded? Would you mind merging if you think it is acceptable.

[pettyjamesm]

I saw this change in Trino after it had merged. I tried to reproduce the described behavior but what I saw seemed to indicate that setting this value actually has no effect and that there's some other implementation detail on the Glue end that actually determines how many partitions will be included in any given response. That said, hard coding a value should be harmless enough: I can't think of a use case that would want any less than the maximum partitions per response and the maximum allowed values for APIs like this tend not to change all that often.

[aweisberg]

@pettyjamesm feel free to merge if you approve :-)

[pettyjamesm]

@pettyjamesm feel free to merge if you approve :-)

The Facebook Integration step not being completed means that this PR hasn't met the "all checks must pass" criteria to merge. Is that something you can trigger on your side or will this PR need to be force-pushed to re-run?

[aweisberg]

Updated to see if that will trigger an integration build. I think there is almost no chance it would do that, but not worth risking.

[pettyjamesm]

Merged, thanks!