pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Antonin Houska <ah@cybertec.at>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
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: Fri, 01 Mar 2019 17:14:25 +0100
Message-ID: <12892.1551456865@localhost> (raw)
In-Reply-To: <5C7928C7.50507@lab.ntt.co.jp>
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>

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:

> (2019/03/01 20:00), Antonin Houska wrote:
> > Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp>  wrote:

> > I used gdb to help me understand, however the condition
> >
> > 	if (fpextra&&  !IS_UPPER_REL(foreignrel))
> >
> > never evaluated to true with the query above.
> 
> 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?

-- 
Antonin Houska
https://www.cybertec-postgresql.com




view thread (48+ messages)  latest in thread

Message-ID: <12892.1551456865@localhost>
Permalink:  ../12892.1551456865@localhost/
Also on:    postgresql.org/message-id/12892.1551456865@localhost

 · 

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: ah@cybertec.at, fujita.etsuro@lab.ntt.co.jp, tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk
  Subject: Re: Problems with plan estimates in postgres_fdw
  In-Reply-To: <12892.1551456865@localhost>

* 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