Re: Question about commit 11cf92f6e2e13c0a6e3f98be3e629e6bd90b74d5

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question about commit 11cf92f6e2e13c0a6e3f98be3e629e6bd90b74d5
Date: 2019-03-05 16:03:24
Message-ID: CA+TgmobZ3Ky7vWTze8NS6DbAo9Jdgq8cQq84p-_8dFyzW0oY8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 5, 2019 at 3:00 AM Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> apply_projection_to_path() not only jams the given tlist into the
> existing path but updates its tlist eval costs appropriately except for
> the cases of Gather and GatherMerge:

I had forgotten that detail, but I don't think it changes the basic
picture. Once you've added a bunch of Paths to a RelOptInfo, it's too
late to change their *relative* cost, because add_path() puts the list
in a certain order, and adjusting the path costs won't change that
ordering. You've got to have the costs already correct at the time
add_path() is first called for any given Path.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shawn Debnath 2019-03-05 16:07:15 Re: Refactoring the checkpointer's fsync request queue
Previous Message Jesper Pedersen 2019-03-05 15:57:57 Re: speeding up planning with partitions