GitLab

see https://github.com/pandas-dev/pandas/issues/28034

We switch every timezone-aware series into utc now.

This is useful for specialized inserters.

Everythin series related in `series.sql` and
less spaghetti method calls involved.

We maintin the series name -> table name there.

Doing a bisection should help with big insertion date lists.

Also we extract the lookup fonctionality.
Some bisection there could help a bit.

A bit too complicated, was done before the fast path
in formula plugin.

If needed we will re-investigate the need to handle
degenerated cases (e.g. hourly insertion of a daily
average).

It works only within one process.
Either we go distributed, which is painful,
or we re-add later transaction scoped caches,
which will need a little work on the `cn` objects.

This brought difficulties: it was impossible to remove
anything from there, for little benefits.

Log has temporarily lost the ability to log cross-series
but a few unions will bring this back later.

Also we rename:

* registry.seriename -> registry.seriesname
* registry.table_name -> registry.tablename

The `tsh.timeserie` namespace is renamed to `tsh.revision`.

closes #54

The only client was the staircase and now
it has its own dedicated path.

We want it the revision list to happen in `history`
to allow tshistory_formula to use it at will
(and in a different way).

This can achieve a nice performance improvement (time and memory wise)
since we can query less series.

Performance implications:

historycache:
DELTA all value dates 0.5080251693725586
DELTA 1 day  0.04896068572998047

prune:
DELTA all value dates 0.5207259654998779
DELTA 1 day  0.03272509574890137


We lose a bit on the commplete horizon but get nice benefits on the
small one. We might want to rewrite the prune function for speed ...

Also move `_revision` to the private methods zone.

This opens the door to a new `revisions` parameter
which allows to pass a precomputed revisions list.

We introduce a generic `historycache` providing
`get` and `staircase` methods.

The `historycache` object embeds the output of a call to `history` for
further use.


Performance implications:

correctness:
DELTA all value dates 1.174530267715454
DELTA 1 day  0.05773115158081055

historycache:
DELTA all value dates 0.5080251693725586
DELTA 1 day  0.04896068572998047

On the whole horizon we get a nice speed up (> 100%) and even the one
day horizon gets slightly faster. This is good.

We get the base dates from the current series value dates.
For each of those we query one point, then concatenate
the result.

Conceptually much simpler to grasp.
Bonus side effect: staircase discrepencies of formula vs alias
extensions have disappeared.

Performance implications:

base:
DELTA all value dates 0.9304628372192383
DELTA 1 day  0.10948061943054199

correctness:
DELTA all value dates 1.174530267715454
DELTA 1 day  0.05773115158081055

So on the whole horizon we are a tad slower but there is an
interesting speedup already in a well-bounded case. This is not bad.

It does not make sense to expose them.

Convenient to have an history as a dataframe.

The only untested command is of course broken.

Specializers might need to build their own insert variant
using this.