Re: make add_paths_to_append_rel aware of startup cost

From: Andy Fan <zhihuifan1213(at)163(dot)com>
To: Andy Fan <zhihuifan1213(at)163(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: make add_paths_to_append_rel aware of startup cost
Date: 2024-02-15 08:38:03
Message-ID: 87a5o2i0ev.fsf@163.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Andy Fan <zhihuifan1213(at)163(dot)com> writes:

> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
>
>> On Thu, Oct 5, 2023 at 9:07 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>>> Thanks. Pushed.
>>
>> FYI somehow this plan from a8a968a8212e flipped in this run:
>>
>> === dumping /home/bf/bf-build/mylodon/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/regression.diffs
>> ===
>> diff -U3 /home/bf/bf-build/mylodon/HEAD/pgsql/src/test/regress/expected/union.out
>> /home/bf/bf-build/mylodon/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/results/union.out
>> --- /home/bf/bf-build/mylodon/HEAD/pgsql/src/test/regress/expected/union.out
>> 2024-01-15 00:31:13.947555940 +0000
>> +++ /home/bf/bf-build/mylodon/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/results/union.out
>> 2024-02-14 00:06:17.075584839 +0000
>> @@ -1447,9 +1447,9 @@
>> -> Append
>> -> Nested Loop
>> Join Filter: (t1.tenthous = t2.tenthous)
>> - -> Seq Scan on tenk1 t1
>> + -> Seq Scan on tenk2 t2
>> -> Materialize
>> - -> Seq Scan on tenk2 t2
>> + -> Seq Scan on tenk1 t1
>> -> Result
>> (8 rows)
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2024-02-14%2000%3A01%3A03
>
> Thanks for this information! I will take a look at this.

I found the both plans have the same cost, I can't get the accurate
cause of this after some hours research, but it is pretty similar with
7516056c584e3, so I uses a similar strategy to stable it. is it
acceptable?

--
Best Regards
Andy Fan

Attachment Content-Type Size
v1-0001-Attempt-to-stabilize-new-unionall-limit-regressio.patch text/x-diff 2.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2024-02-15 08:53:30 Re: [PATCH] Expose port->authn_id to extensions and triggers
Previous Message Andrei Lepikhov 2024-02-15 07:35:57 Re: planner chooses incremental but not the best one