On Mon, 18 Mar 2024 at 18:50, Ashutosh Bapat
wrote:
> If the problem you speculate is different from this one, I am not able to see
> it. It might help give an example query or explain more.
I looked at this again and I might have been wrong about there being a
problem. I set a breakpoint in cr
On Thu, Mar 14, 2024 at 3:45 PM David Rowley wrote:
> On Thu, 14 Mar 2024 at 18:23, Ashutosh Bapat
> wrote:
> > I don't understand why root->query_pathkeys has both a and b. "a" is
> there because of GROUP BY and ORDER BY clause. But why "b"?
>
> So that the ORDER BY aggregate function can be ev
On Thu, 14 Mar 2024 at 12:00, David Rowley wrote:
> I've attached a patch which fixes the problem for me.
I've pushed the patch to fix gather_grouping_paths(). The issue with
the RelOptInfo having the incorrect PathTarget->exprs after the
partial phase of partition-wise aggregate remains.
David
On Thu, 14 Mar 2024 at 18:23, Ashutosh Bapat
wrote:
> I don't understand why root->query_pathkeys has both a and b. "a" is there
> because of GROUP BY and ORDER BY clause. But why "b"?
So that the ORDER BY aggregate function can be evaluated without
nodeAgg.c having to perform the sort. See
adju
On Thu, Mar 14, 2024 at 4:30 AM David Rowley wrote:
> On Thu, 14 Mar 2024 at 06:00, Alexander Lakhin
> wrote:
> > I've stumbled upon the same error, but this time it apparently has
> another
> > cause. It can be produced (on REL_16_STABLE and master) as follows:
> > CREATE TABLE t (a int, b int)
On Thu, 14 Mar 2024 at 06:00, Alexander Lakhin wrote:
> I've stumbled upon the same error, but this time it apparently has another
> cause. It can be produced (on REL_16_STABLE and master) as follows:
> CREATE TABLE t (a int, b int) PARTITION BY RANGE (a);
> CREATE TABLE td PARTITION OF t DEFAULT;
Hello David,
09.10.2023 07:13, David Rowley wrote:
On Mon, 9 Oct 2023 at 12:42, David Rowley wrote:
Maybe it's worth checking the total planning time spent in a run of
the regression tests with and without the patch to see how much
overhead it adds to the "average case".
I've now pushed the p
On Mon, Oct 9, 2023 at 12:13 PM David Rowley wrote:
> I've now pushed the patch that trims off the Pathkeys for the ORDER BY
> / DISTINCT aggregates.
Thanks for pushing!
> Those results are a bit noisy. Perhaps a few more runs might yield
> more consistency, but it seems that there's not too
On Mon, 9 Oct 2023 at 12:42, David Rowley wrote:
> Maybe it's worth checking the total planning time spent in a run of
> the regression tests with and without the patch to see how much
> overhead it adds to the "average case".
I've now pushed the patch that trims off the Pathkeys for the ORDER BY
On Mon, Oct 9, 2023 at 7:42 AM David Rowley wrote:
> On Sun, 8 Oct 2023 at 23:52, Richard Guo wrote:
> > If the pathkeys that were added by adjust_group_pathkeys_for_groupagg()
> > are computable from the targetlist, it seems that we do not need to trim
> > them off, because prepare_sort_from_pa
On Sun, 8 Oct 2023 at 23:52, Richard Guo wrote:
> On Thu, Oct 5, 2023 at 2:26 PM David Rowley wrote:
>>
>> So in short, I propose the attached fix without any regression tests
>> because I feel that any regression test would just mark that there was
>> a big in create_agg_path() and not really he
On Thu, Oct 5, 2023 at 2:26 PM David Rowley wrote:
> So in short, I propose the attached fix without any regression tests
> because I feel that any regression test would just mark that there was
> a big in create_agg_path() and not really help with ensuring we don't
> end up with some similar pro
On Tue, 3 Oct 2023 at 20:16, David Rowley wrote:
> I wonder if the attached patch is too much of a special case fix. I
> guess from the lack of complaints previously that there are no other
> cases where we could possibly have pathkeys that belong to columns
> that are aggregated. I've not gone
On Tue, 3 Oct 2023 at 09:11, David Rowley wrote:
> I'm concerned that this patch will be too much overhead when creating
> paths when a PathKey's EquivalenceClass has a large number of members
> from partitioned tables.
I just tried out the patch to see how much it affects the performance
of the
On Tue, 19 Sept 2023 at 23:45, Richard Guo wrote:
> My first thought about the fix is that we artificially add resjunk
> target entries to parse->targetList for the ordered aggregates'
> arguments that are ORDER BY expressions, as attached. While this can
> fix the given query, it would cause Ass
On Mon, Sep 18, 2023 at 10:02 PM Justin Pryzby wrote:
> This fails since 1349d2790b
>
> commit 1349d2790bf48a4de072931c722f39337e72055e
> Author: David Rowley
> Date: Tue Aug 2 23:11:45 2022 +1200
>
> Improve performance of ORDER BY / DISTINCT aggregates
>
> ts=# CREATE TABLE t (a int, b t
16 matches
Mail list logo
