Re: Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Tue, Mar 5, 2019 at 3:46 AM David Steele wrote: > I have marked this entry as targeting PG13 since it is too late to > consider for PG12. Sounds right. As Peter said himself, this patch is WIP, so it's too soon to consider integrating it. This is also fairly evident from the content of the

Re: Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

Hi Peter, On 2/28/19 11:43 PM, Peter Moser wrote: Dear all, we rebased our temporal normalization patch on top of 554ebf687852d045f0418d3242b978b49f160f44 from 2019-02-28. I will also add this prototype (WIP) patch to the commitfest of March, as suggested by two developers met at the

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

Dear all, we rebased our temporal normalization patch on top of 554ebf687852d045f0418d3242b978b49f160f44 from 2019-02-28. On 9/7/18 1:02 PM, Peter Moser wrote: > The syntax is > SELECT * FROM (r NORMALIZE s USING() WITH(period_r, period_s)) c; Please find all information about our decisions

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On 01/26/2018 07:55 AM, Peter Moser wrote: We have now a new approach to plan and execute NORMALIZE as a special join node of type NORMALIZE, an append-plan on the inner join path, and a merge-join executor. For the latter, we would need to extend nodeMergejoin.c with an

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Mon, 2018-01-08 at 11:18 -0500, Robert Haas wrote: > I also don't agree with the idea that we should reject syntax that > doesn't appear in the SQL standard. We have a great deal of such > syntax already, and we add more of it in every release, and a good > deal of it is contributed by you and

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Sun, 2018-01-07 at 09:58 +, Simon Riggs wrote: > > The attached README explains the ALIGN operation step-by-step with > > a TEMPORAL LEFT OUTER JOIN example. That is, we start from a query > > input, show how we rewrite it during parser stage, and show how the > > final execution generates

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Sat, 2018-01-06 at 20:29 +, Simon Riggs wrote: > * various PostJoinSetProjection() functions to be called as needed > So the idea is we enable Postgres to allow major new functionality, > as was done for PostGIS so successfully. If we use a post-join approach many intermediate result

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Thu, 2017-11-30 at 12:26 -0500, Robert Haas wrote: > I wonder if we could instead think about R NORMALIZE S ON R.x = S.y > WITH (R.time, S.time) as an ordinary join on R.x = S.y with some > extra processing afterwards. After finding all the join partners for > a row in R, extract all the lower

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Sat, Jan 6, 2018 at 3:29 PM, Simon Riggs wrote: > I'm not very keen on adopting new syntax that isn't in the > SQLStandard. They have a bad habit of doing something completely > different. So a flexible approach will allow us to have functionality > now and we can adopt

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On 30 March 2017 at 13:11, Peter Moser wrote: > 2017-03-01 10:56 GMT+01:00 Peter Moser : >> A similar walkthrough for ALIGN will follow soon. >> >> We are thankful for any suggestion or ideas, to be used to write a >> good SGML documentation. > > The

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On 30 November 2017 at 17:26, Robert Haas wrote: > I wonder if we could instead think about R NORMALIZE S ON R.x = S.y > WITH (R.time, S.time) as an ordinary join on R.x = S.y with some extra > processing afterwards. That would work nicely, kindof like a Projection, but

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Tue, Nov 21, 2017 at 4:36 AM, Peter Moser wrote: > Hi hackers, > we like to rethink our approach... > > For simplicity I'll drop ALIGN for the moment and focus solely on NORMALIZE: > > SELECT * FROM (R NORMALIZE S ON R.x = S.y WITH (R.time, S.time)) c; > > Our

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Tue, Nov 21, 2017 at 6:36 PM, Peter Moser wrote: > 2017-11-14 18:42 GMT+01:00 Tom Lane : >> You might consider putting the rewriting into, um, the rewriter. >> It could be a separate pass after view expansion, if direct integration >> with the existing

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

2017-11-14 18:42 GMT+01:00 Tom Lane : > You might consider putting the rewriting into, um, the rewriter. > It could be a separate pass after view expansion, if direct integration > with the existing behavior seems unduly spaghetti-ish.  Or do it in > an early phase of planning

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

2017-11-14 18:42 GMT+01:00 Tom Lane : > Robert is correct that putting this into the parser is completely the > wrong thing. If you do that, then for example views using the features > will reverse-list in the rewritten form, which we Do Not Want, even > if the rewritten form

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

2017-11-11 13:19 GMT+01:00 Robert Haas : > 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

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

2017-10-06 19:22 GMT+02:00 Paul A Jungwirth : > 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 >