[DISCUSSION] Remove totalHits feature from pagination in V2

[Yury-Fridlyand]

Is your feature request related to a problem?

A discussion started from this post in #1497 raised a question: should we implement this feature or remove it (revert)?

If we keep this feature

Procs

1. Compatibility with legacy engine
2. Proper use of total and size in the response - these values were always equal before

Cons

1. Rework required, implementation is not good
2. It is not used; main consumer of JDBC response format is the JDBC driver which ignores both these values

If we remove this feature

Procs

1. Reduce impact of pagination feature

Cons

1. A breaking change: legacy engine properly sets total and size for paging requests
   Note: it is still not used by JDBC (ref: JsonQueryResponse).

Please, feel free to edit procs/cons lists above and post your votes. Removal was already discussed in meetings and in the slack channel, but should be posted/copied here for visibility.

[penghuo]

Is it possible,

1. if the request from JDBC, execute in new engine, ignore total field.
2. if the request from others, fallback to legacy.

[Yury-Fridlyand]

@penghuo,
Could you please clarify a bit:

if the request from JDBC, execute in new engine, ignore total field.

What does mean ignore? Return total equal to size as it was before (breaking with V1) or not to return it at all (breaking at all)?

if the request from others, fallback to legacy.

That means any paging request in non-jdbc format will be processed in V1. Why?
Note: legacy engine does not support paging for non-jdbc format too - it returns non-paged results (aka ignores fetch_size).

[penghuo]

1. If the request from JDBC driver, does total hits field required? if not required, we can ignore it.
2. Ignore my comments of "if the request from others, fallback to legacy"

[Yury-Fridlyand]

Complete by #1649