Pavel Stehule pavel.steh...@gmail.com 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
2013/2/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Pavel Stehule pavel.steh...@gmail.com 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
2013/2/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
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
SubPlan
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
