Re: [PROPOSAL] Temporal query processing with range types

From: Mike Rylander <mrylander(at)gmail(dot)com>
To: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: Anton Dignös <dignoes(at)inf(dot)unibz(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Johann Gamper <gamper(at)inf(dot)unibz(dot)it>, Michael Böhlen <boehlen(at)ifi(dot)uzh(dot)ch>, Moser Peter <peter(dot)moser(at)unibz(dot)it>
Subject: Re: [PROPOSAL] Temporal query processing with range types
Date: 2017-10-06 19:22:52
Message-ID: CAO8ar=kxUD82PHzT1MHEA2g9iyXxswSAanvOeJAPCa7sBn4y6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 6, 2017 at 1:22 PM, Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
> On Fri, Jul 22, 2016 at 4:15 AM, Anton Dignös <dignoes(at)inf(dot)unibz(dot)it> wrote:
>> We would like to contribute to PostgreSQL a solution that supports the query
>> processing of "at each time point". The basic idea is to offer two new
>> operators, NORMALIZE and ALIGN, whose purpose is to adjust (or split) the
>> ranges of tuples so that subsequent queries can use the usual grouping and
>> equality conditions to get the intended results.
>
> I just wanted to chime in and say that the work these people have done
> is *amazing*. I read two of their papers yesterday [1, 2], and if you
> are interested in temporal data, I encourage you to read them too. The
> first one is only 12 pages and quite readable. After that the second
> is easy because it covers a lot of the same ground but adds "scaling"
> of values when a tuple is split, and some other interesting points.
> Their contributions could be used to implement SQL:2011 syntax but go
> way beyond that.
>

I've also been following this feature with great interest, and would
definitely throw whatever tiny weight I have, sitting out here in the
the peanut gallery, behind accepting the ALIGN and NORMALIZE syntax.
I estimate that about a third of the non-trivial queries in the
primary project I work on (and have, on Postgres, for the last 13+
years) would be simpler with support of the proposed syntax, and some
of the most complex business logic would be simplified nearly to the
point of triviality.

Anyway, that's my $0.02.

Thank you, Anton and Peter!

-- Mike

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-10-06 19:27:26 Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Previous Message Ashutosh Bapat 2017-10-06 19:07:51 Re: Partition-wise join for join between (declaratively) partitioned tables