On Fri, 16 Feb 2024 at 01:09, David Rowley wrote:
>
> On Thu, 15 Feb 2024 at 21:42, Andy Fan wrote:
> > 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
David Rowley writes:
> I'd be more happy using this one as percentage-wise, the cost
> difference is much larger.
+1 for the percentage-wise.
>
> I checked that the t2.thounsand = 0 query still tests the cheap
> startup paths in add_paths_to_append_rel().
I get the same conclusion here.
>
>
On Thu, 15 Feb 2024 at 21:42, Andy Fan wrote:
> 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?
It's pretty hard to say. I
Andy Fan writes:
> Thomas Munro writes:
>
>> On Thu, Oct 5, 2023 at 9:07 PM David Rowley wrote:
>>> Thanks. Pushed.
>>
>> FYI somehow this plan from a8a968a8212e flipped in this run:
>>
>> === dumping
>>
Thomas Munro writes:
> On Thu, Oct 5, 2023 at 9:07 PM David Rowley 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
On Thu, Oct 5, 2023 at 9:07 PM David Rowley 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
On Thu, 5 Oct 2023 at 14:11, Andy Fan wrote:
> Patch LGTM.
Thanks. Pushed.
David
On Wed, Oct 4, 2023 at 8:41 AM David Rowley wrote:
> On Sun, 1 Oct 2023 at 21:26, Andy Fan wrote:
> >> But overall, I'm more inclined to just go with the more simple "add a
> >> cheap unordered startup append path if considering cheap startup
> >> plans" version. I see your latest patch does
On Sun, 1 Oct 2023 at 21:26, Andy Fan wrote:
>> But overall, I'm more inclined to just go with the more simple "add a
>> cheap unordered startup append path if considering cheap startup
>> plans" version. I see your latest patch does both. So, I'd suggest two
>> patches as I do see the merit in
Hi David,
But overall, I'm more inclined to just go with the more simple "add a
> cheap unordered startup append path if considering cheap startup
> plans" version. I see your latest patch does both. So, I'd suggest two
> patches as I do see the merit in keeping this simple and cheap. If we
>
On Mon, 18 Sept 2023 at 22:55, Andy Fan wrote:
> Here is an updated version to show what's in my mind.
My current thoughts on this are that the fractional cost part adds
quite a bit more complexity than the minimalistic approach of just
also considering the cheapest startup path.
There's also
Hi,
> What do you think about this in my last reply? "If my above
> analysis is correct, I think the best way to handle this is if there
> is no more tables to join, we use cheapest fraction cost for all
> the kinds of relations, including plain relation, append rel,
> subquery and so on,
On Mon, Sep 18, 2023 at 11:58 AM David Rowley wrote:
> On Mon, 18 Sept 2023 at 01:42, Andy Fan wrote:
> > On Fri, Sep 15, 2023 at 3:15 PM David Rowley
> wrote:
> >> Instead of doing that, why don't you just create a completely new
> >> AppendPath containing all the cheapest_startup_paths and
On Mon, 18 Sept 2023 at 01:42, Andy Fan wrote:
> On Fri, Sep 15, 2023 at 3:15 PM David Rowley wrote:
>> Instead of doing that, why don't you just create a completely new
>> AppendPath containing all the cheapest_startup_paths and add that to
>> the append rel. You can optimise this and only do
Hi David,
Thanks for taking a look at this!
On Fri, Sep 15, 2023 at 3:15 PM David Rowley wrote:
> On Thu, 7 Sept 2023 at 04:37, Andy Fan wrote:
> > Currently add_paths_to_append_rel overlooked the startup cost for
> creating
> > append path, so it may have lost some optimization chances.
On Thu, 7 Sept 2023 at 04:37, Andy Fan wrote:
> Currently add_paths_to_append_rel overlooked the startup cost for creating
> append path, so it may have lost some optimization chances. After a glance,
> the following 4 identifiers can be impacted.
> - We shouldn't do the optimization if there
> - We shouldn't do the optimization if there are still more tables to join,
> the reason is similar to has_multiple_baserels(root) in
> set_subquery_pathlist.
>
After some internal discussion, we have 2 different choices here. Let's
call the current choice as method-a, and the new choice as
Hi:
This thread is a refactor of thread [1] for easier communication.
Currently add_paths_to_append_rel overlooked the startup cost for creating
append path, so it may have lost some optimization chances. After a
glance,
the following 4 identifiers can be impacted.
Identifier 1:
SELECT ..
18 matches
Mail list logo
