David Rowley writes:
> Thank you for the report. I've just pushed a patch which I'm hoping will fix
> it.
Passes now on my VM.
regards, tom lane
On Fri, 4 Aug 2023 at 11:54, Nathan Bossart wrote:
> I'm seeing some reliable test failures for 32-bit builds on cfbot [0]. At
> a glance, it looks like the relations are swapped in the plan.
Thank you for the report. I've just pushed a patch which I'm hoping will fix it.
David
Nathan Bossart writes:
> On Fri, Aug 04, 2023 at 09:28:51AM +1200, David Rowley wrote:
>> Thank you for reviewing. I've pushed the patch to master only.
> I'm seeing some reliable test failures for 32-bit builds on cfbot [0]. At
> a glance, it looks like the relations are swapped in the plan.
On Fri, Aug 04, 2023 at 09:28:51AM +1200, David Rowley wrote:
> Thank you for reviewing. I've pushed the patch to master only.
I'm seeing some reliable test failures for 32-bit builds on cfbot [0]. At
a glance, it looks like the relations are swapped in the plan.
[0]
https://api.cirrus-ci.com/
On Fri, 4 Aug 2023 at 02:02, Andy Fan wrote:
> I have checked the updated patch and LGTM.
Thank you for reviewing. I've pushed the patch to master only.
David
On Thu, 3 Aug 2023 at 05:50, David Rowley wrote:
> I'm currently thinking it's
> a bad idea to backpatch this but I'd consider it more if someone else
> thought it was a good idea or if more people came along complaining
> about poor plan choice in plans containing WindowAggs. Currently, it
> see
On Thu, Aug 3, 2023 at 7:29 PM David Rowley wrote:
> Thanks for having a look at this.
>
> On Thu, 3 Aug 2023 at 18:49, Andy Fan wrote:
> > 1. ORDER BY or PARTITION BY
> >
> > select *, count(two) over (order by unique1) from tenk1 limit 1;
> > DEBUG: startup_tuples = 1
> > DEBUG: startup_tupl
Thanks for having a look at this.
On Thu, 3 Aug 2023 at 18:49, Andy Fan wrote:
> 1. ORDER BY or PARTITION BY
>
> select *, count(two) over (order by unique1) from tenk1 limit 1;
> DEBUG: startup_tuples = 1
> DEBUG: startup_tuples = 1
>
> select *, count(two) over (partition by unique1) from ten
Hi David:
Sorry for feedback at the last minute! I study the patch and find the
following cases.
1. ORDER BY or PARTITION BY
select *, count(two) over (order by unique1) from tenk1 limit 1;
DEBUG: startup_tuples = 1
DEBUG: startup_tuples = 1
select *, count(two) over (partition by unique1) f
On Wed, 31 May 2023 at 12:59, David Rowley wrote:
>
> On Wed, 12 Apr 2023 at 21:03, David Rowley wrote:
> > I'll add this to the "Older bugs affecting stable branches" section of
> > the PG 16 open items list
>
> When I wrote the above, it was very soon after the feature freeze for
> PG16. I wond
On Wed, 12 Apr 2023 at 21:03, David Rowley wrote:
> I'm not sure if we should consider backpatching a fix for this bug.
> We tend not to commit stuff that would destabilise plans in the back
> branches. On the other hand, it's fairly hard to imagine how we
> could make this much worse even given
On Thu, 13 Apr 2023 at 10:09, David Rowley wrote:
> I also see I might need to do a bit more work on this as the following
> is not handled correctly:
>
> select count(*) over(rows between unbounded preceding and 10
> following) from tenk1;
>
> it's assuming all rows due to lack of ORDER BY, but i
On Thu, Apr 13, 2023 at 6:09 AM David Rowley wrote:
> .On Thu, 13 Apr 2023 at 02:28, Andy Fan wrote:
> > The concept of startup_tuples for a WindowAgg looks good to me, but I
> > can't follow up with the below line:
> >
> > + return clamp_row_est(partition_tuples * DEFAULT_INEQ_SEL);
> >
> > # s
.On Thu, 13 Apr 2023 at 02:28, Andy Fan wrote:
> The concept of startup_tuples for a WindowAgg looks good to me, but I
> can't follow up with the below line:
>
> + return clamp_row_est(partition_tuples * DEFAULT_INEQ_SEL);
>
> # select count(*) over() from tenk1 limit 1;
> count
> ---
> 1000
On Wed, Apr 12, 2023 at 5:04 PM David Rowley wrote:
>
> With the attached patch, that turns into:
>
The concept of startup_tuples for a WindowAgg looks good to me, but I
can't follow up with the below line:
+ return clamp_row_est(partition_tuples * DEFAULT_INEQ_SEL);
# select count(*) over() f
Over on [1], Tim reported that the planner is making some bad choices
when the plan contains a WindowFunc which requires reading all of, or
a large portion of the WindowAgg subnode in order to produce the first
WindowAgg row.
For example:
EXPLAIN (ANALYZE, TIMING OFF)
SELECT COUNT(*) OVER ()
FROM
16 matches
Mail list logo
