On 3/28/18 2:23 PM, Andres Freund wrote:
> On 2018-03-28 14:18:42 -0400, David Steele wrote:
>> It seems that a new patch is needed here but none has been presented.
>> I've marked this Waiting on Author for the moment, but I really think it
>> should be marked Returned with Feedback and submitted
Hi,
On 2018-03-28 14:18:42 -0400, David Steele wrote:
> It seems that a new patch is needed here but none has been presented.
> I've marked this Waiting on Author for the moment, but I really think it
> should be marked Returned with Feedback and submitted to the next CF
> when a new patch is read
On 3/2/18 11:44 AM, Robert Haas wrote:
> On Fri, Mar 2, 2018 at 11:12 AM, Alexander Kuzmenkov
> wrote:
>> On 16.01.2018 10:49, Jeff Davis wrote:
>>> My proposed fix is to make an internal opfamily identical to the
>>> external one, such that it's not recognized as part of the same EC,
>>> and the
On Fri, Mar 2, 2018 at 11:12 AM, Alexander Kuzmenkov
wrote:
> On 16.01.2018 10:49, Jeff Davis wrote:
>> My proposed fix is to make an internal opfamily identical to the
>> external one, such that it's not recognized as part of the same EC,
>> and the planner won't try to eliminate it. It loses out
On 16.01.2018 10:49, Jeff Davis wrote:
My proposed fix is to make an internal opfamily identical to the
external one, such that it's not recognized as part of the same EC,
and the planner won't try to eliminate it. It loses out on potential
optimizations, but those are mostly theoretical since th
On Tue, Jan 23, 2018 at 2:04 AM, Simon Riggs wrote:
> Perhaps we are misunderstanding each other
>
> TIMESTAMP <@ RANGE1 doesn't match if RANGE1 is empty
> and that is the most important case
When <@ is supported, that case should be fine if range1 is on the
outer. The case I was concerned about
On 23 January 2018 at 05:08, Jeff Davis wrote:
> On Fri, Jan 19, 2018 at 2:07 AM, Simon Riggs wrote:
>> err... that isn't correct. An empty range matches nothing, so can be
>> ignored in joins.
>>
>> So probably best to explain some more, please.
>
> The semantics of R1 @> R2 will return true if
On Fri, Jan 19, 2018 at 2:07 AM, Simon Riggs wrote:
> err... that isn't correct. An empty range matches nothing, so can be
> ignored in joins.
>
> So probably best to explain some more, please.
The semantics of R1 @> R2 will return true if R1 is a non-NULL range
and R2 is empty.
It's set semanti
On 19 January 2018 at 08:25, Simon Riggs wrote:
> On 17 January 2018 at 05:49, Jeff Davis wrote:
>> On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs wrote:
>>> Do we optimize for TIMESTAMP <@ RANGE as well?
>>
>> Not currently. It requires a little extra complexity because empty
>> ranges will match
On 17 January 2018 at 05:49, Jeff Davis wrote:
> On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs wrote:
>> Do we optimize for TIMESTAMP <@ RANGE as well?
>
> Not currently. It requires a little extra complexity because empty
> ranges will match anything and need special handling.
TIMESTAMP <@ RANGE
On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs wrote:
> Do we optimize for TIMESTAMP <@ RANGE as well?
Not currently. It requires a little extra complexity because empty
ranges will match anything and need special handling.
> Does this link in nicely with partition-aware joins?
Yes: if the partit
On Fri, Jan 12, 2018 at 11:02 AM, Alexander Kuzmenkov
wrote:
> The sort order isn't right for the join, it seems. I remember having similar
> troubles with my full merge join implementation. I tried filtering
> unsuitable paths in try_mergejoin_path, but that was not quite enough. The
> planner tr
On Tue, Jan 9, 2018 at 11:24 PM, Jeff Davis wrote:
>> Just to emphasise why we want this, it might be better for the EXPLAIN
>> to say "Time Range Join" when the ranges being joined are Time Ranges,
>> and for other cases to just say "Range Join". The use of the word
>> Merge doesn't help much the
Hi Jeff,
Just a quick comment -- I ran a slightly modified version of a query
from the regression tests, and got an assertion failure:
select i1, ir1, i2, ir2
from (select * from rangejoin_left order by ir1 desc) as a1 inner
join (select * from rangejoin_right order by ir2 desc) as a2
On 10 January 2018 at 04:24, Jeff Davis wrote:
> Done.
I think you need to make changes to other parts of the docs also, so
that it is clear what will now be possible
https://www.postgresql.org/docs/devel/static/using-explain.html
https://www.postgresql.org/docs/devel/static/xoper-optimization.
On 10 January 2018 at 04:24, Jeff Davis wrote:
> On Sat, Jan 6, 2018 at 10:38 AM, Simon Riggs wrote:
>> For this to be useful, it needs to include some details of how to use
>> it when people have NOT used range datatypes in their tables.
>
> Good idea. I added an example that doesn't have range
On Sat, Jan 6, 2018 at 10:38 AM, Simon Riggs wrote:
> For this to be useful, it needs to include some details of how to use
> it when people have NOT used range datatypes in their tables.
Good idea. I added an example that doesn't have range types in the base table.
> If we can see some examples
On 29 December 2017 at 18:25, Jeff Davis wrote:
> New rangejoin patch attached.
>
> I had previously attempted to make this work well for multiple range
> join keys, but this patch implements single rangejoin keys only, and
> the rest of the rangejoin clauses are effectively just rechecks. I
> bel
18 matches
Mail list logo
