Optimization of recursive view

I have an optimization problem when using a recursive view on PostgreSQL. When I perform a trivial query using this view, the execution time is abnormally long.

To expose my problem, here is a database, with the view and the query that causes the problem: http://sqlfiddle.com/#!17/9d39e/13

The main table is v_univ_st and the view is called v_univ_bf.
EXPLAIN

I tried the EXPLAIN method of PostgreSQL, here is the result I get (the table I'm working on is much bigger than the fiddle one):
`"Hash Right Join (cost=4724036209.97..4757553915.67 rows=1510012 width=23746) (actual time=5172.917..24833.100 rows=1869 loops=1)"
" Hash Cond: ((recipes_flat."PRODUCT_ID")::text = (u_sample_tasks."PRODUCT_ID")::text)"
" -> CTE Scan on recipes_flat (cost=4723991547.19..4728513371.25 rows=164429966 width=23705) (actual time=0.197..19761.488 rows=367312 loops=1)"
" CTE recipes_flat"
" -> Recursive Union (cost=0.00..4723991547.19 rows=164429966 width=15645) (actual time=0.181..17845.438 rows=367312 loops=1)"
" -> Seq Scan on v_univ_st (cost=0.00..8024046.44 rows=279636 width=1824) (actual time=0.171..3060.524 rows=279684 loops=1)"
" SubPlan 1"
" -> Aggregate (cost=28.54..28.55 rows=1 width=0) (actual time=0.007..0.007 rows=1 loops=279684)"
" -> Index Only Scan using idx_recipe_blends_ingredient_id on v_univ_st sr (cost=0.42..28.52 rows=6 width=0) (actual time=0.004..0.006 rows=0 loops=279684)"
" Index Cond: ("INGREDIENT_ID" = (v_univ_st."PRODUCT_ID_COMP")::text)"
" Heap Fetches: 68468"
" -> Nested Loop (cost=0.42..471267890.14 rows=16415033 width=15645) (actual time=0.262..799.437 rows=9736 loops=9)"
" -> WorkTable Scan on recipes_flat s (cost=0.00..55927.20 rows=2796360 width=14718) (actual time=0.010..22.153 rows=40812 loops=9)"
" ->

By using a materialized view and EXISTS, I lowered the execution time of the request by about 96%.
I have changed :
CREATE OR REPLACE VIEW public.v_univ_bf


To
CREATE MATERIALIZED VIEW public.v_univ_bf


The materialized view is not refreshed with each query that uses it, it must be refreshed if changes have been made to the table.

For my problem, I refresh the materialized view every day with a query in my ETL but here is a topic that presents all the methods to refresh a materialized view.

StackExchange Database Administrators Q#293768, answer score: 3