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 ha
I wrote:
>> Stephen Frost 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 blocker
> is
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
> relat
Tom Lane writes:
> Stephen Frost 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
Stephen Frost 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 the sam
* 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 sub-se
Kyotaro HORIGUCHI 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
> with apparently wrong row num
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 a
