2013/2/11 Tom Lane :
> Pavel Stehule writes:
>>> no, there is strange estimation
>>>
>>> SubPlan 2
>>> -> CTE Scan on pl pl_1 (cost=0.00..468.59
>>> rows=89000 width=4) (actual time=0.023..8.379 rows=566 loops=1000)
>>> Output: foo(pl_1.a)
>
> Nothing strange about it. 89 rows out from the unde
Pavel Stehule writes:
>> no, there is strange estimation
>>
>> SubPlan 2
>> -> CTE Scan on pl pl_1 (cost=0.00..468.59
>> rows=89000 width=4) (actual time=0.023..8.379 rows=566 loops=1000)
>> Output: foo(pl_1.a)
Nothing strange about it. 89 rows out from the underlying CTE (which
appears to be
>
> no, there is strange estimation
>
> -> Seq Scan on public.x2 (cost=0.00..345560.00 rows=500
> width=4) (actual time=17.914..9330.645 rows=133 loops=1)
>Output: x2.a
>Filter: (NOT (SubPlan 2))
>Rows Removed by Filter: 867
>
2013/2/11 Tom Lane :
> Pavel Stehule writes:
>> In Czech discussion group was reported performance regression of CTE
>> query. I wrote a test, when I can show it.
>
> I don't see anything tremendously wrong here. The older branches are
> choosing the right plan for entirely wrong reasons: they do
Pavel Stehule writes:
> In Czech discussion group was reported performance regression of CTE
> query. I wrote a test, when I can show it.
I don't see anything tremendously wrong here. The older branches are
choosing the right plan for entirely wrong reasons: they don't notice
that "select foo(a)
Hello
In Czech discussion group was reported performance regression of CTE
query. I wrote a test, when I can show it.
Execution on 9.2, 9.3 is about 9 sec, on 8.4, 9.1 is about 30ms with
default work_mem ='1MB'
optimal plan (8.4)
QUERY PLAN
