Hello, thank you for the considerations by all of you, but I have
described incorrectly the situation. I'm terribly sorry for the
imprecise description and for your additional work based on it.
The point of this issue is not VAULES but the nature of Append
and NestLoop. Nested Loop can fail to
I wrote:
Stephen Frost sfr...@snowman.net writes:
I've certainly seen and used values() constructs in joins for a variety
of reasons and I do think it'd be worthwhile for the planner to know how
to pull up a VALUES construct.
I spent a bit of time looking at this, and realized that the
I wrote:
Hm, the problem evidently is that we get a default selectivity estimate
for the ON condition. I think a proper fix for this would involve
teaching eqjoinsel (and ideally other join selectivity functions) how
to drill down into appendrels and combine estimates for the child
* Tom Lane (t...@sss.pgh.pa.us) wrote:
BTW, is that JOIN (VALUES(...)) thing common in applications, or did you
just use it to make a compact example? If it were something worth
optimizing, it seems like we could teach the planner to pull up VALUES
in the same way that it flattens
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes:
Hello, I had a report that a query gets wired estimated row
numbers and it makes subsequent plans wrong.
Although the detailed explanation is shown later in this mail,
the problem here was that a query like following makes the path
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
BTW, is that JOIN (VALUES(...)) thing common in applications, or did you
just use it to make a compact example? If it were something worth
optimizing, it seems like we could teach the planner to pull up VALUES
in
Tom Lane t...@sss.pgh.pa.us writes:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
BTW, is that JOIN (VALUES(...)) thing common in applications, or did you
just use it to make a compact example? If it were something worth
optimizing, it seems like we could
Hello, I had a report that a query gets wired estimated row
numbers and it makes subsequent plans wrong.
Although the detailed explanation is shown later in this mail,
the problem here was that a query like following makes the path
with apparently wrong row number.
EXPLAIN SELECT a FROM (SELECT
