David Rowley writes:
> No objections from me.
Pushed, thanks for looking at it.
regards, tom lane
On Wed, 18 Jan 2023 at 11:51, Tom Lane wrote:
> If nobody has any comments on this, I'm going to go ahead and push
> it. The value of the improvement is rapidly paling in comparison
> to the patch's maintenance effort.
No objections from me.
David
On Wed, 18 Jan 2023 at 14:55, Richard Guo wrote:
> Yeah, I noticed this too yesterday. I reviewed through these two
> patches yesterday and I think they are in good shape now.
I'm currently reviewing the two patches.
David
On Wed, Jan 18, 2023 at 6:51 AM Tom Lane wrote:
> I wrote:
> > Yeah, sideswiped by 3c6fc5820 apparently. No substantive change needed.
>
> And immediately sideswiped by da5800d5f.
Yeah, I noticed this too yesterday. I reviewed through these two
patches yesterday and I think they are in good
I wrote:
> Yeah, sideswiped by 3c6fc5820 apparently. No substantive change needed.
And immediately sideswiped by da5800d5f.
If nobody has any comments on this, I'm going to go ahead and push
it. The value of the improvement is rapidly paling in comparison
to the patch's maintenance effort.
On Sun, Jan 15, 2023 at 5:23 AM Tom Lane wrote:
> vignesh C writes:
> > The patch does not apply on top of HEAD as in [1], please post a rebased
> patch:
>
> Yeah, sideswiped by 3c6fc5820 apparently. No substantive change needed.
I looked through these two patches and they look good to me.
vignesh C writes:
> The patch does not apply on top of HEAD as in [1], please post a rebased
> patch:
Yeah, sideswiped by 3c6fc5820 apparently. No substantive change needed.
regards, tom lane
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/postgres_fdw/deparse.c
On Sat, 31 Dec 2022 at 02:32, Tom Lane wrote:
>
> I wrote:
> > Richard Guo writes:
> >> While we are here, I wonder if we can do the same trick for
> >> distinctClause, to cope with cases like
> >> select distinct a.x, b.y from a, b where a.x = b.y;
>
> > We do that already, no?
>
> Oh, wait, I
I wrote:
> Richard Guo writes:
>> While we are here, I wonder if we can do the same trick for
>> distinctClause, to cope with cases like
>> select distinct a.x, b.y from a, b where a.x = b.y;
> We do that already, no?
Oh, wait, I see what you mean: we are smart in code paths that rely
on
Richard Guo writes:
> On Wed, Dec 28, 2022 at 6:18 AM Tom Lane wrote:
>> This patch is aimed at being smarter about cases where we have
>> redundant GROUP BY entries, for example
>> SELECT ... WHERE a.x = b.y GROUP BY a.x, b.y;
> While we are here, I wonder if we can do the same trick for
>
On Wed, Dec 28, 2022 at 6:18 AM Tom Lane wrote:
> This patch is aimed at being smarter about cases where we have
> redundant GROUP BY entries, for example
>
> SELECT ... WHERE a.x = b.y GROUP BY a.x, b.y;
>
> It's clearly not necessary to perform grouping using both columns.
> Grouping by either
I wrote:
> This patch is aimed at being smarter about cases where we have
> redundant GROUP BY entries, for example
> SELECT ... WHERE a.x = b.y GROUP BY a.x, b.y;
The cfbot didn't like this, because of a variable that wasn't
used in non-assert builds. Fixed in v2.
This patch is aimed at being smarter about cases where we have
redundant GROUP BY entries, for example
SELECT ... WHERE a.x = b.y GROUP BY a.x, b.y;
It's clearly not necessary to perform grouping using both columns.
Grouping by either one alone would produce the same results,
assuming compatible
13 matches
Mail list logo
