2017-01-18 3:57 GMT+01:00 Peter Eisentraut <peter.eisentr...@2ndquadrant.com>: > > On 1/13/17 9:22 AM, Peter Moser wrote: > > The goal of temporal aligners and normalizers is to split ranges to allow a > > reduction from temporal queries to their non-temporal counterparts. > > Splitting > > ranges is necessary for temporal query processing. Temporal aligners and > > normalizer may then be used as building-blocks for any temporal query > > construct. > > I would need to see the exact definitions of these constructs. Please > send some documentation. > > > We have published two papers, that contain formal definitions and > > related work > > for the temporal aligner and normalizer. Please see [1] and [2]. > > I don't have access to those.
The papers can be freely downloaded from http://www.inf.unibz.it/~dignoes/publications.html using the "Author-ize link". > >> I think there are probably many interesting applications for normalizing > >> or otherwise adjusting ranges. I'd like to see an overview and > >> consideration of other applications. > > > > Please see the attached file adjustment.sql for some interesting > > applications. > > That's surely interesting, but without knowing what these operations are > supposed to do, I can only reverse engineer and guess. Intuitively what they do is as follows: NORMALIZE: splits all the ranges of one relation according to all the range boundaries of another (but possibly the same) relation whenever some equality condition over some given attributes is satisfied. When the two relations are the same, all ranges with the given equal attributes are either equal or disjoint. After this, the traditional GROUP BY or DISTINCT can be applied. The attributes given to NORMALIZE for a (temporal) GROUP BY are the grouping attributes and for a (temporal) DISTINCT the target list attributes. When the two relations are different, but they each contain disjoint ranges for the same attributes (as the current limitation for the set operations is) we perform a symmetric NORMALIZE on each of them. Then we have a similar situation as before, i.e., in both relations ranges with the same attributes are either equal or disjoint and a traditional set operation (EXCEPT/INTERSECT/UNION) can be applied. The attributes given to NORMALIZE for a (temporal) EXCEPT/INTERSECT/UNION are the target list attributes. ALIGN: splits all the ranges of one relation according to all the range intersections of another relation, i.e., it produces all intersections and non-overlapping parts, whenever some condition is satisfied. We perform a symmetric ALIGN on each relation, after which a traditional inner or outer join can be applied using equality on the ranges to calculate the overlap. The condition given to a (temporal) inner or outer join is the join condition without overlap. > >> Ideally, I'd like to see these things implemented as some kind of > >> user-space construct, like an operator or function. I think we'd need a > >> clearer definition of what it is they do before we can evaluate that. > > > > Can you please explain what you mean by "user-space construct" in this case. > > Implement them using the extensibility features, such as a user-defined > operator. I don't know if it's possible, but it's something to consider. We experimented with user-defined operators and set-returning functions. The main issue with these is that ALIGN and NORMALIZE rely on comparison and processing of one tuple with many tuples at a time that is not possible with operators, and for set-returning functions there is no clean way of passing tables and/or conditions. > Using common terms such as ALIGN and NORMALIZE for such a specific > functionality seems a bit wrong. Would ALIGN RANGES/RANGE ALIGN and NORMALIZE RANGES/RANGE NORMALIZE be better options? We are also thankful for any suggestion or comments about the syntax. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
