On Fri, Jul 19, 2024 at 12:00 PM Alexander Lakhin wrote:
> 18.07.2024 17:30, Richard Guo wrote:
> > I have no idea why the underlying statistics changed, but it seems
> > that this slight change is sufficent to result in a different plan.
>
> I think it could be caused by the same reason as [1] an
Hello Richard,
18.07.2024 17:30, Richard Guo wrote:
The problemed plan is a non-parallel nestloop join. It's just chance
which join order the planner will pick, and slight variations in
underlying statistics could result in a different displayed plan.
From the two verbose plans, we can see sli
On Thu, Jul 18, 2024 at 4:11 PM Richard Guo wrote:
> On Thu, Jul 18, 2024 at 4:00 PM Alexander Lakhin wrote:
> > Please look at a recent buildfarm failure [1], which shows some
> > instability of that test addition:
> > -- the joinrel is not parallel-safe due to the OFFSET clause in the
> > su
On Thu, Jul 18, 2024 at 4:00 PM Alexander Lakhin wrote:
> Please look at a recent buildfarm failure [1], which shows some
> instability of that test addition:
> -- the joinrel is not parallel-safe due to the OFFSET clause in the subquery
> explain (costs off)
> select * from tenk1 t1, (s
Hello Richard,
12.07.2024 05:29, Richard Guo wrote:
On Sat, Jul 6, 2024 at 5:32 PM Richard Guo wrote:
Here is a new rebase.
I'm planning to push it next week, barring any objections.
Pushed.
Please look at a recent buildfarm failure [1], which shows some
instability of that test addition:
Richard Guo 于2024年7月12日周五 10:30写道：
> On Sat, Jul 6, 2024 at 5:32 PM Richard Guo wrote:
> > Here is a new rebase.
> >
> > I'm planning to push it next week, barring any objections.
>
> Pushed.
>
> Thanks
> Richard
>
Thanks for pushing.
--
Tender Wang
On Sat, Jul 6, 2024 at 5:32 PM Richard Guo wrote:
> Here is a new rebase.
>
> I'm planning to push it next week, barring any objections.
Pushed.
Thanks
Richard
On Wed, Jun 19, 2024 at 10:55 AM Tender Wang wrote:
> Richard Guo 于2024年6月18日周二 17:24写道：
>> I updated the patch to include a check in consider_parallel_nestloop
>> ensuring that inner_cheapest_total is not parameterized by outerrel
>> before materializing it. I also tweaked the comments, test ca
Richard Guo 于2024年6月18日周二 17:24写道：
> On Tue, Jun 4, 2024 at 6:51 PM Tender Wang wrote:
> > Yeah, Richard commented the v1 patch about JOIN_UNIQUE_INNER in [1]
> >
> > * I think we should not consider materializing the cheapest inner path
> > if we're doing JOIN_UNIQUE_INNER, because in this case
On Tue, Jun 4, 2024 at 6:51 PM Tender Wang wrote:
> Yeah, Richard commented the v1 patch about JOIN_UNIQUE_INNER in [1]
>
> * I think we should not consider materializing the cheapest inner path
> if we're doing JOIN_UNIQUE_INNER, because in this case we have to
> unique-ify the inner path.
>
> We
Hi Robert,
Since this patch had been reviewed at PgConf.dev Patch Review
Workshop. And I have updated
the patch according to the review advice. Now there are no others to
comment this patch.
The status of this patch on commitfest have stayed "need review" for a long
time.
I want to know if it
Hi. Tender.
> From: Tender Wang
> Sent: Tuesday, June 11, 2024 5:11 PM
>
> > From: Tender Wang mailto:tndrw...@gmail.com> >
> > Sent: Tuesday, June 4, 2024 7:51 PM
> > Please add more tests. Especially please add some negative
> tests;
> > current patch chec
fujii.y...@df.mitsubishielectric.co.jp <
fujii.y...@df.mitsubishielectric.co.jp> 于2024年6月5日周三 09:26写道：
> Hi. Tender.
>
> Thank you for modification.
>
> > From: Tender Wang
> > Sent: Tuesday, June 4, 2024 7:51 PM
> > Please add more tests. Especially please add some negative tests;
> >
Hi. Tender.
Thank you for modification.
> From: Tender Wang
> Sent: Tuesday, June 4, 2024 7:51 PM
> Please add more tests. Especially please add some negative tests;
> current patch checks that it is safe to apply materialization. It would
> be helpful to add tests checking th
Tomasz Rybak 于2024年5月31日周五 04:21写道：
> On Tue, 2024-04-23 at 16:59 +0800, Tender Wang wrote:
> >
> [ cut ]
> >
> > I have rebased master and fixed a plan diff case.
>
> We (me, Paul Jungwirth, and Yuki Fujii) reviewed this patch
> at PgConf.dev Patch Review Workshop.
>
Thanks for reviewing this p
On Tue, 2024-04-23 at 16:59 +0800, Tender Wang wrote:
>
[ cut ]
>
> I have rebased master and fixed a plan diff case.
We (me, Paul Jungwirth, and Yuki Fujii) reviewed this patch
at PgConf.dev Patch Review Workshop.
Here are our findings.
Patch tries to allow for using materialization together
w
Andrey M. Borodin 于2024年4月8日周一 17:40写道：
>
>
> > On 27 Sep 2023, at 16:06, tender wang wrote:
> >
> >Do you have any comments or suggestions on this issue? Thanks.
> Hi Tender,
>
> there are some review comments in the thread, that you might be interested
> in.
> I'll mark this [0] entry "Wai
Andrey M. Borodin 于2024年4月8日周一 17:40写道：
>
>
> > On 27 Sep 2023, at 16:06, tender wang wrote:
> >
> >Do you have any comments or suggestions on this issue? Thanks.
> Hi Tender,
>
> there are some review comments in the thread, that you might be interested
> in.
> I'll mark this [0] entry "Wai
> On 27 Sep 2023, at 16:06, tender wang wrote:
>
>Do you have any comments or suggestions on this issue? Thanks.
Hi Tender,
there are some review comments in the thread, that you might be interested in.
I'll mark this [0] entry "Waiting on Author" and move to next CF.
Thanks!
Best rega
Hi!
Thank you for your work on the subject.
I reviewed your patch and found that your commit message does not fully
explain your code, in addition, I found several spelling mistakes.
I think it's better to change to:
With parallel seqscan, we should consider materializing the cheapest
inne
On Fri, 8 Sept 2023 at 19:14, Richard Guo wrote:
> explain select * from partsupp join lineitem on l_partkey > ps_partkey;
> QUERY PLAN
> --
> Gather (cost=0.00..1807085.44 r
On Fri, 8 Sept 2023 at 09:41, Robert Haas wrote:
>
> On Tue, Sep 5, 2023 at 8:07 AM Richard Guo wrote:
> > Yeah, this seems an omission in commit 45be99f8.
>
> It's been a while, but I think I omitted this deliberately because I
> didn't really understand the value of it and wanted to keep the
>
Hi tom,
Do you have any comments or suggestions on this issue? Thanks.
Richard Guo 于2023年9月8日周五 14:06写道：
>
> On Fri, Sep 8, 2023 at 3:15 AM Robert Haas wrote:
>
>> The example query provided here seems rather artificial. Surely few
>> people write a join clause that references neither of the
On Fri, Sep 8, 2023 at 3:15 AM Robert Haas wrote:
> The example query provided here seems rather artificial. Surely few
> people write a join clause that references neither of the tables being
> joined. Is there a more realistic case where this makes a big
> difference?
Yes the given example qu
On Tue, Sep 5, 2023 at 8:07 AM Richard Guo wrote:
> Yeah, this seems an omission in commit 45be99f8.
It's been a while, but I think I omitted this deliberately because I
didn't really understand the value of it and wanted to keep the
planning cost down.
The example query provided here seems rath
Richard Guo 于2023年9月5日周二 18:51写道：
>
> On Tue, Sep 5, 2023 at 4:52 PM tender wang wrote:
>
>>I recently run benchmark[1] on master, but I found performance problem
>> as below:
>> ...
>>
>> I debug the code and find consider_parallel_nestloop() doesn't consider
>> materialized form of the che
On Tue, Sep 5, 2023 at 4:52 PM tender wang wrote:
>I recently run benchmark[1] on master, but I found performance problem
> as below:
> ...
>
> I debug the code and find consider_parallel_nestloop() doesn't consider
> materialized form of the cheapest inner path.
>
Yeah, this seems an omissi
After using patch, the result as below :
QUERY
PLAN
Limit (cost=1078.00..26630101.20
Hi all,
I recently run benchmark[1] on master, but I found performance problem
as below:
explain analyze select
subq_0.c0 as c0,
subq_0.c1 as c1,
subq_0.c2 as c2
from
(select
ref_0.l_shipmode as c0,
sample_0.l_orderkey as c1,
sample_0.l_quantity as c2,
r
29 matches
Mail list logo
