On 18 September 2018 at 20:02, Antonin Houska wrote:
> Following are the findings from my review.
Thanks for reviewing this. Time is short in this commitfest to make
any changes, so I'm going to return this with feedback with the
intention of addressing the items from your review for the next 'f
David Rowley wrote:
> I've attached an updated version of this patch.
Following are the findings from my review.
On the LATERAL references:
This query (proposed upthread by Tom and adjusted by me so it can be executed
on the your test tables)
select distinct t1.id from t1 left join t2 on t1.i
On 4 March 2018 at 21:43, David Rowley wrote:
> Please find attached two patches. The first of which is intended to
> resolve the issue mentioned above with consideration that it may need
> to be back-patched to where LEFT JOIN removals where introduced.
>
> Patch two is intended to implement LEFT
On 5 March 2018 at 04:19, Tom Lane wrote:
> select * from t1, t2 where notice(t2.a) = t1.a;
> select * from t1, t2 where notice(t2.a) = t2.b;
>
> With our current implementation, the first will result in executing
> notice() for every row pair in the cross product, while the second
> will evaluate
David Rowley writes:
> On 10 January 2018 at 08:44, Tom Lane wrote:
>> select distinct nextval('foo') from a left join b ...
>> The presence of the DISTINCT again doesn't excuse changing how often
>> nextval() gets called.
> While working on the cases where the join removal should be disallowed
On 4 March 2018 at 18:35, David Rowley wrote:
> drop table if exists t1;
>
> create table t1 (a int);
> insert into t1 values(1);
>
> create or replace function notice(pn int) returns int as $$
> begin
> raise notice '%', pn;
> return pn;
> end;
> $$ volatile language plpgsql;
>
> create unique in
On 10 January 2018 at 08:44, Tom Lane wrote:
> select distinct nextval('foo') from a left join b ...
>
> The presence of the DISTINCT again doesn't excuse changing how often
> nextval() gets called.
>
> I kinda doubt this list of counterexamples is exhaustive, either;
> it's just what occu
On 2018-03-02 10:14:52 +1300, David Rowley wrote:
> One observation is that it appears you're already running damage
> control to triage the patches that will certainly not make it. I don't
> think this particular patch is overly complex, so is that really a
> good thing to do on the first of the m
On 2 March 2018 at 09:59, Andres Freund wrote:
> If a patch hasn't been updated after moved waiting-on-author from the
> last CF, and the next CF started, that seems too late. Particularly in
> the last CF.
I understand that I should have resolved these issues before the
commitfest, so please do
On 2018-03-02 09:57:35 +1300, David Rowley wrote:
> On 2 March 2018 at 09:56, Andres Freund wrote:
> > On 2018-03-02 09:53:38 +1300, David Rowley wrote:
> >> I'm planning on making the required changes at the weekend.
> >
> > Sorry if I'm grumpy, but why shouldn't this just mean it's slipped to
>
On 2 March 2018 at 09:56, Andres Freund wrote:
> On 2018-03-02 09:53:38 +1300, David Rowley wrote:
>> On 2 March 2018 at 09:49, Andres Freund wrote:
>> > On 2018-01-10 11:14:27 +1300, David Rowley wrote:
>> >> On 10 January 2018 at 08:44, Tom Lane wrote:
>> >> > I'll set the patch back to Waitin
On 2018-03-02 09:53:38 +1300, David Rowley wrote:
> On 2 March 2018 at 09:49, Andres Freund wrote:
> > On 2018-01-10 11:14:27 +1300, David Rowley wrote:
> >> On 10 January 2018 at 08:44, Tom Lane wrote:
> >> > I'll set the patch back to Waiting on Author.
> >>
> >> Many thanks for looking at this
On 2 March 2018 at 09:49, Andres Freund wrote:
> On 2018-01-10 11:14:27 +1300, David Rowley wrote:
>> On 10 January 2018 at 08:44, Tom Lane wrote:
>> > I'll set the patch back to Waiting on Author.
>>
>> Many thanks for looking at this. I'll try to resolve the things you've
>> mentioned this comi
On 2018-01-10 11:14:27 +1300, David Rowley wrote:
> On 10 January 2018 at 08:44, Tom Lane wrote:
> > I'll set the patch back to Waiting on Author.
>
> Many thanks for looking at this. I'll try to resolve the things you've
> mentioned this coming weekend.
This hasn't happened yet. As the last CF
On 10 January 2018 at 08:44, Tom Lane wrote:
> I'll set the patch back to Waiting on Author.
Many thanks for looking at this. I'll try to resolve the things you've
mentioned this coming weekend.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
David Rowley writes:
> [ remove_left_join_distinct_2017-11-30.patch ]
I looked at this, and it seems like an interesting idea, but I'm
unconvinced that the specific conditions here are OK.
One clear problem is that you consider a DISTINCT to be an automatic
get-out-of-jail-free card, but that do
On 1 December 2017 at 01:40, Ashutosh Bapat
wrote:
> The patch looks good to me.
> It applies cleanly, compiles on my laptop without warnings or errors.
> make check does not show any failures. Marking it as ready for
> committer.
Great. Many thanks for the review!
--
David Rowley
On Thu, Nov 30, 2017 at 12:20 PM, David Rowley
wrote:
> Thanks for looking over this and my apologies for the delay in my
> response. I've been on leave and out of range of the internet for most
> of that time.
>
> On 23 November 2017 at 02:30, Ashutosh Bapat
> wrote:
>>
>> @@ -597,15 +615,25 @@
Thanks for looking over this and my apologies for the delay in my
response. I've been on leave and out of range of the internet for most
of that time.
On 23 November 2017 at 02:30, Ashutosh Bapat
wrote:
>
> @@ -597,15 +615,25 @@ rel_supports_distinctness(PlannerInfo *root,
> RelOptInfo *rel)
> +
On Wed, Nov 22, 2017 at 10:30 PM, Ashutosh Bapat
wrote:
> On Wed, Nov 1, 2017 at 5:39 AM, David Rowley
> wrote:
>
>> In this case, the join *can* cause row duplicates, but the distinct or
>> group by would filter these out again anyway, so in these cases, we'd
>> not only get the benefit of not j
On Wed, Nov 1, 2017 at 5:39 AM, David Rowley
wrote:
> In this case, the join *can* cause row duplicates, but the distinct or
> group by would filter these out again anyway, so in these cases, we'd
> not only get the benefit of not joining but also not having to remove
> the duplicate rows caused
21 matches
Mail list logo
