pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feed From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Antonin Houska <ah@cybertec.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Problems with plan estimates in postgres_fdw
Date: Tue, 05 Mar 2019 17:11:18 +0900
Message-ID: <5C7E2F26.8020402@lab.ntt.co.jp> (raw )
In-Reply-To: <12892.1551456865@localhost >
References: <87pnz1aby9.fsf@news-spur.riddles.org.uk >
<1175.1533220908@sss.pgh.pa.us >
<5BB739CD.6040002@lab.ntt.co.jp >
<5BBC4140.50403@lab.ntt.co.jp >
<5C17A00E.5000005@lab.ntt.co.jp >
<5C232F39.9060509@lab.ntt.co.jp >
<5C25C7B5.2010802@lab.ntt.co.jp >
<5C518631.5080401@lab.ntt.co.jp >
<10994.1549559088@localhost >
<5C5D778F.3080501@lab.ntt.co.jp >
<19433.1549962210@localhost >
<5C669DFD.30002@lab.ntt.co.jp >
<16616.1550234762@localhost >
<5C6A5FD3.8080102@lab.ntt.co.jp >
<30524.1550499671@localhost >
<5C6BBD7A.1030702@lab.ntt.co.jp >
<29190.1550843669@localhost >
<5C73C403.7080109@lab.ntt.co.jp >
<7273.1551438041@localhost >
<5C7928C7.50507@lab.ntt.co.jp >
<12892.1551456865@localhost >
(2019/03/02 1:14), Antonin Houska wrote:
> Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp> wrote:
>> (2019/03/01 20:00), Antonin Houska wrote:
>> Sorry, my explanation was not enough again, but I showed that query ("SELECT
>> a+b, random() FROM foreign_table GROUP BY a+b ORDER BY a+b;") to explain why
>> the following code bit is needed:
>>
>> + /*
>> + * If this includes an UPPERREL_ORDERED step, the given target, which
>> + * would be the final target to be applied to the resulting path,
>> might
>> + * have different expressions from the underlying relation's reltarget
>> + * (see make_sort_input_target()); adjust tlist eval costs.
>> + */
>> + if (fpextra&& fpextra->target != foreignrel->reltarget)
>> + {
>> + QualCost oldcost = foreignrel->reltarget->cost;
>> + QualCost newcost = fpextra->target->cost;
>> +
>> + startup_cost += newcost.startup - oldcost.startup;
>> + total_cost += newcost.startup - oldcost.startup;
>> + total_cost += (newcost.per_tuple - oldcost.per_tuple) * rows;
>> + }
>
> Maybe I undestand now. Do the expressions (newcost.* - oldcost.*) reflect the
> fact that, for the query
>
> SELECT a+b, random() FROM foreign_table GROUP BY a+b ORDER BY a+b;
>
> the UPPERREL_ORDERED stage only needs to evaluate the random() function
> because (a + b) was already evaluated during the UPPERREL_GROUP_AGG stage?
Yeah, I think so.
Best regards,
Etsuro Fujita
view thread (48+ messages) latest in thread
Message-ID: <5C7E2F26.8020402@lab.ntt.co.jp>
Permalink: ../5C7E2F26.8020402@lab.ntt.co.jp/
Also on: postgresql.org/message-id/5C7E2F26.8020402@lab.ntt.co.jp
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: fujita.etsuro@lab.ntt.co.jp, ah@cybertec.at, tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk
Subject: Re: Problems with plan estimates in postgres_fdw
In-Reply-To: <5C7E2F26.8020402@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox