2017-11-11 13:19 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
> This is really good input. If the feature weren't useful, then it
> wouldn't make sense to try to figure out how to integrate it, but if
> it is, then we should try.
We are happy to hear this and will do the implementation. Any input
regarding the implementation is much appreciated.
> I don't think that implementing a feature like this by SQL
> transformation can work. It's certainly got the advantage of
> simplicity of implemention, but there are quite a few things that seem
> like they won't always work correctly.
> [...]
> Overall, I think that the whole approach here probably needs to be
> scrapped and rethought. The stuff this patch is doing really belongs
> in the optimizer, not the parser, I think. It could possibly happen
> at a relatively early stage in the optimizer so that the rest of the
> optimizer can see the results of the transformation and, well,
> optimize. But parse time is way too early.
We create this query rewrites during parser stage, because we want
that the optimizer chooses the best strategies for each rewritten
subplan and that our executor nodes get the desired input format in
the most optimal way. Our goal was an integration that re-uses the
existing PostgreSQL rewrites and optimizations fully.
Another approach is to optimize the temporal primitives manually.
This does not reuse existing PostgreSQL optimizations automatically.
Is there a general guideline or policy as to which approach is
preferable?
Regarding all the other issues, we will look into them in detail and
report back soon.
Best regards,
Anton, Johann, Michael, Peter
