From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: disfavoring unparameterized nested loops |
Date: | 2021-06-21 18:26:41 |
Message-ID: | 1655681.1624300001@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> ... As an example,
> select * from t1, t2 where t1.id = constant and t1.x op t2.y;
> where I'm not assuming much about the properties of "op".
> This could be amenable to a plan like
> NestLoop Join
> Join Filter: t1.x op t2.y
> -> Index Scan on t1_pkey
> Index Cond: t1.id = constant
> -> Seq Scan on t2
Also, to enlarge on that example: if "op" isn't hashable then the
original argument is moot. However, it'd still be useful to know
if the outer scan is sure to return no more than one row, as that
could inform the choice whether to plaster a Materialize node on
the inner scan.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-06-21 18:49:09 | Re: disfavoring unparameterized nested loops |
Previous Message | Tom Lane | 2021-06-21 17:38:28 | Re: disfavoring unparameterized nested loops |