Start bisecting after getting min/max from first database

Some databases are awfully slow at getting min(id) and max(id) for a column when WHERE is added to the mix, for example, for this query in Snowflake, it takes 50s on a dataset in the millions of rows:

Running SQL (Snowflake): SELECT min(id), max(id) FROM TRANSFERS WHERE ('2022-06-04T14:27:44.096619' <= created_at) AND (created_at < '2022-06-14T13:57:44.096658')

In Postgres, the same query takes a few millis.

It’s going to be rare they’re different, so instead, we can just use the fast one and start bisecting.

When the second, slower database returns min + max, we compare with the faster one’s. If it’s not the same min/max, we’ll warn, and could restart the bisection. Alternatively, we can just start bisecting at the extremes if min/max are now extended, so it’s very graceful.

E.g. it should look like this:

Thread1, Time 00:00:00: Postgres: select min(id), max(id) from table
Thread2, Time 00:00:00: Snowflake: select min(id), max(id) from table
Thread1 Time 00:00:01: Postgres returns min=1, max=1000
... start bisecting ...
Thread2, Time 00:00:10: Snowflake returns min=1, max=1000
... continues bisecting because min + max are the same...

This should improve performance substantially on some platforms.

[sirupsen]

Looks awesome @erezsh

[erezsh]

@sirupsen Actually turned out to be pretty elegant!