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 p
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
FOSDEM
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 and
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 point-in-range-containmen
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
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 r
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 tuples
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
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 any new syntax later.
>
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 attached README explains the ALIGN operation st
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 one that can
vary the num
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 normalization executor node ne
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 behavior seems unduly spaghetti-ish. Or d
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 as he suggested. The
On Thu, Nov 16, 2017 at 3:32 AM, Peter Moser wrote:
> Thank you for your feedback. We'll have a look at this and come back to you.
Another thing to think about is that even though the CURRENT
implementation just rewrites the relevant constructs as SQL, in the
future somebody might want to do some
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 is completely valid S
Peter Moser writes:
> 2017-11-11 13:19 GMT+01:00 Robert Haas :
>> 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 e
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 input
regarding the imple
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
> first one is only 12 pages and qu
19 matches
Mail list logo
