# Using a materialized view as another materialized view as base timeout / OOM

**URL:** <https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839>\
**Category:** Community\
**Tags:** bug\
**Created:** [May 26, 2025, 4:56pm UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839 "2025-05-26T16:56:31Z")\
**Posts on this page:** 10\
**Page:** 2

<div class="post-metadata">

**Author:** ![JForsaken](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/jforsaken/32/398_2.png) [@JForsaken](https://community.questdb.com/u/JForsaken)\
**Post date:** [May 29, 2025, 7:01am UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/21 "2025-05-29T07:01:01Z")

</div>

Just tried dropping `cairo.mat.view.rows.per.query.estimate` to 500k like you’ve suggested,  
confimed it is applied through ` (SHOW PARAMETERS) WHERE reloadable = true;`, having 500k as a value.

Was able to create the `holdings_hourly` view using the base table (`accounting_delta`) 👍  
Was able to create the daily view using the `holdings_hourly` as base 👍  
But with this same setting, getting an OOM doing `holdings_monthly` using the `holdings_daily` as my base ❌

Here is the MV creation DDL and the logs:

```auto
2025-05-28 20:36:52.573 EDT
2025-05-29T00:36:52.572163Z E i.q.c.s.a.PageFrameReduceJob reduce error [error=
2025-05-28 20:36:52.573 EDT
io.questdb.cairo.CairoException: [-1] global RSS memory limit exceeded [usage=40557095895, RSS_MEM_LIMIT=40587440940, size=67108864, memoryTag=29] at io.questdb.cairo.CairoException.instance(CairoException.java:370) at io.questdb.cairo.CairoException.nonCritical(CairoException.java:128) at io.questdb.std.Unsafe.checkAllocLimit(Unsafe.java:352) at io.questdb.std.Unsafe.realloc(Unsafe.java:280) at io.questdb.cairo.map.OrderedMap.resize(OrderedMap.java:591) at io.questdb.cairo.map.OrderedMap$Key.checkCapacity(OrderedMap.java:868) at io.questdb.cairo.map.OrderedMap$FixedSizeKey.init(OrderedMap.java:649) at io.questdb.cairo.map.OrderedMap$FixedSizeKey.init(OrderedMap.java:621) at io.questdb.cairo.map.OrderedMap.withKey(OrderedMap.java:388) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursorFactory.aggregateSharded(AsyncGroupByRecordCursorFactory.java:359) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursorFactory.aggregate(AsyncGroupByRecordCursorFactory.java:242) at io.questdb.cairo.sql.async.PageFrameReduceJob.reduce(PageFrameReduceJob.java:241) at io.questdb.cairo.sql.async.PageFrameReduceJob.consumeQueue(PageFrameReduceJob.java:189) at io.questdb.cairo.sql.async.PageFrameReduceJob.run(PageFrameReduceJob.java:150) at io.questdb.mp.Worker.run(Worker.java:152)
2025-05-28 20:36:52.573 EDT
, id=2, taskType=1, frameIndex=2094, frameCount=2159]
2025-05-28 20:36:52.622 EDT
2025-05-29T00:36:52.620794Z E i.q.c.s.a.PageFrameReduceJob reduce error [error=
2025-05-28 20:36:52.622 EDT
io.questdb.cairo.CairoException: [-1] global RSS memory limit exceeded [usage=40557095511, RSS_MEM_LIMIT=40587440940, size=67108864, memoryTag=29] at io.questdb.cairo.CairoException.instance(CairoException.java:370) at io.questdb.cairo.CairoException.nonCritical(CairoException.java:128) at io.questdb.std.Unsafe.checkAllocLimit(Unsafe.java:352) at io.questdb.std.Unsafe.realloc(Unsafe.java:280) at io.questdb.cairo.map.OrderedMap.resize(OrderedMap.java:591) at io.questdb.cairo.map.OrderedMap$Key.checkCapacity(OrderedMap.java:868) at io.questdb.cairo.map.OrderedMap$FixedSizeKey.init(OrderedMap.java:649) at io.questdb.cairo.map.OrderedMap$FixedSizeKey.init(OrderedMap.java:621) at io.questdb.cairo.map.OrderedMap.withKey(OrderedMap.java:388) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursorFactory.aggregateSharded(AsyncGroupByRecordCursorFactory.java:359) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursorFactory.aggregate(AsyncGroupByRecordCursorFactory.java:242) at io.questdb.cairo.sql.async.PageFrameReduceJob.reduce(PageFrameReduceJob.java:241) at io.questdb.cairo.sql.async.PageFrameReduceJob.consumeQueue(PageFrameReduceJob.java:189) at io.questdb.cairo.sql.async.PageFrameReduceJob.run(PageFrameReduceJob.java:150) at io.questdb.mp.Worker.run(Worker.java:152)
2025-05-28 20:36:52.622 EDT
, id=2, taskType=1, frameIndex=2096, frameCount=2159]
2025-05-28 20:36:54.782 EDT
2025-05-29T00:36:54.781619Z E i.q.g.e.QueryProgress err [id=8, sql=`
2025-05-28 20:36:54.782 EDT
SELECT
2025-05-28 20:36:54.782 EDT
timestamp,
2025-05-28 20:36:54.782 EDT
asset,
2025-05-28 20:36:54.782 EDT
user,
2025-05-28 20:36:54.782 EDT
sum(amount_approx) as amount_approx,
2025-05-28 20:36:54.782 EDT
sum(amount_part1) AS amount_part1,
2025-05-28 20:36:54.782 EDT
sum(amount_part2) AS amount_part2,
2025-05-28 20:36:54.782 EDT
sum(amount_part3) AS amount_part3,
2025-05-28 20:36:54.782 EDT
sum(amount_part4) AS amount_part4,
2025-05-28 20:36:54.782 EDT
sum(amount_part5) AS amount_part5,
2025-05-28 20:36:54.782 EDT
sum(amount_part6) AS amount_part6,
2025-05-28 20:36:54.782 EDT
sum(amount_part7) AS amount_part7,
2025-05-28 20:36:54.782 EDT
sum(amount_part8) AS amount_part8
2025-05-28 20:36:54.782 EDT
FROM holdings_daily
2025-05-28 20:36:54.782 EDT
SAMPLE BY 1M
2025-05-28 20:36:54.782 EDT
`, principal=admin, cache=false, refreshMinTs=2024-07-01T00:00:00.000000Z, refreshMaxTs=2025-05-31T23:59:59.999999Z, jit=true, time=31096398203, msg=global RSS memory limit exceeded [usage=40557095895, RSS_MEM_LIMIT=40587440940, size=67108864, memoryTag=29], errno=-1, pos=0]
2025-05-28 20:36:54.782 EDT
2025-05-29T00:36:54.782159Z E i.q.c.m.MatViewRefreshJob could not refresh materialized view [view=holdings_monthly~507, ex=
2025-05-28 20:36:54.782 EDT
io.questdb.cairo.CairoException: [-1] global RSS memory limit exceeded [usage=40557095895, RSS_MEM_LIMIT=40587440940, size=67108864, memoryTag=29]
	at io.questdb.cairo.CairoException.instance(CairoException.java:370)
	at io.questdb.cairo.CairoException.nonCritical(CairoException.java:128)
	at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.buildMap(AsyncGroupByRecordCursor.java:198)
	at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.buildMapConditionally(AsyncGroupByRecordCursor.java:246)
	at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.hasNext(AsyncGroupByRecordCursor.java:138)
	at io.questdb.griffin.engine.orderby.LongSortedLightRecordCursor.sortValues(LongSortedLightRecordCursor.java:179)
	at io.questdb.griffin.engine.orderby.LongSortedLightRecordCursor.hasNext(LongSortedLightRecordCursor.java:96)
	at io.questdb.griffin.engine.QueryProgress$RegisteredRecordCursor.hasNext(QueryProgress.java:419)
	at io.questdb.cairo.mv.MatViewRefreshJob.insertAsSelect(MatViewRefreshJob.java:472)
	at io.questdb.cairo.mv.MatViewRefreshJob.refreshIncremental0(MatViewRefreshJob.java:921)
	at io.questdb.cairo.mv.MatViewRefreshJob.refreshIncremental(MatViewRefreshJob.java:862)
	at io.questdb.cairo.mv.MatViewRefreshJob.incrementalRefresh(MatViewRefreshJob.java:403)
	at io.questdb.cairo.mv.MatViewRefreshJob.processNotifications(MatViewRefreshJob.java:645)
	at io.questdb.cairo.mv.MatViewRefreshJob.run(MatViewRefreshJob.java:120)
	at io.questdb.mp.Worker.run(Worker.java:152)

```

Any ideas to make the initial refresh job use more appropriate chunks? If not, is it possible for me to create the materialize view in `INCREMENTAL` mode, without it doing the `FULL` refresh upon creation, so that i can use `RANGE` to manually refresh it month by month initially?

Thanks again!

---

<div class="post-metadata">

**Author:** ![JForsaken](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/jforsaken/32/398_2.png) [@JForsaken](https://community.questdb.com/u/JForsaken)\
**Post date:** [May 29, 2025, 7:01am UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/22 "2025-05-29T07:01:09Z")

</div>

If this helps, this is the output for `table_partitions()` of `holdings_daily` , the base table for the `holdings_monthly` from the above – I’m just giving you context since since these are trades, the first days / months are pretty empty, but after ~100 days its really balanced at \> 1M rows of aggregated 1d user/asset pairs a day, to see if the starting empty-ish partitions contribute to an eager estimation, even when I have `cairo.mat.view.rows.per.query.estimate` set to 500000:

 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/249508a49aa5cac030d4be4dc67f2b4b31849b80.png)  
 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/8912ff24f0ab20294e6d810ba97b6482c1671547.png)  
 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/c85d7f08250c5da5d5a5b70fe8c5b3f1f72434c9.png)  
 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/f7d3eca9a06191c52be79a28f81daa01f9b0fd49.png)  
 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/056caf9a553f27a52702c6aaae85ad6d59531807.png)  
 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/c7105d62ff4e4f4d16c94ee0c1e9d008295637c6.png)  
 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/ce88882c1ddc587f324c7b68a611e30d582604a7.png)  
 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/ebb8aff68c839e2952b2e4813ddd784442610221.png)  
 ![image](https://canada1.discourse-cdn.com/flex004/uploads/questdb/original/1X/388505b2a9154a604ec205df086e506b2d9d0854.png)

---

<div class="post-metadata">

**Author:** ![puzpuzpuz](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/puzpuzpuz/32/25_2.png) [@puzpuzpuz](https://community.questdb.com/u/puzpuzpuz)\
**Post date:** [May 29, 2025, 7:25am UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/23 "2025-05-29T07:25:22Z")

</div>

> refreshMinTs=2024-07-01T00:00:00.000000Z, refreshMaxTs=2025-05-31T23:59:59.999999Z

The queried range is still very large. Could you try setting `cairo.mat.view.rows.per.query.estimate` to a smaller value like 10k and then check if these queried intervals get smaller? Since the “density” of the partitions varies a lot, the estimation ends up being too optimistic.

---

<div class="post-metadata">

**Author:** ![JForsaken](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/jforsaken/32/398_2.png) [@JForsaken](https://community.questdb.com/u/JForsaken)\
**Post date:** [May 29, 2025, 9:50pm UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/24 "2025-05-29T21:50:03Z")

</div>

Tried just now at 10k, same RSS OOM issue!

---

<div class="post-metadata">

**Author:** ![JForsaken](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/jforsaken/32/398_2.png) [@JForsaken](https://community.questdb.com/u/JForsaken)\
**Post date:** [May 29, 2025, 9:50pm UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/25 "2025-05-29T21:50:07Z")

</div>

The window didn’t change when changing to 10k (made sure the settings have been reloaded and applied)

```auto
2025-05-29 10:27:04.411 EDT
2025-05-29T14:27:04.410298Z E i.q.c.s.a.PageFrameReduceJob reduce error [error=
2025-05-29 10:27:04.411 EDT
io.questdb.cairo.CairoException: [-1] global RSS memory limit exceeded [usage=40548379804, RSS_MEM_LIMIT=40587440940, size=67108864, memoryTag=29] at io.questdb.cairo.CairoException.instance(CairoException.java:370) at io.questdb.cairo.CairoException.nonCritical(CairoException.java:128) at io.questdb.std.Unsafe.checkAllocLimit(Unsafe.java:352) at io.questdb.std.Unsafe.realloc(Unsafe.java:280) at io.questdb.cairo.map.OrderedMap.resize(OrderedMap.java:591) at io.questdb.cairo.map.OrderedMap$Key.checkCapacity(OrderedMap.java:868) at io.questdb.cairo.map.OrderedMap$FixedSizeKey.init(OrderedMap.java:649) at io.questdb.cairo.map.OrderedMap$FixedSizeKey.init(OrderedMap.java:621) at io.questdb.cairo.map.OrderedMap.withKey(OrderedMap.java:388) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursorFactory.aggregateSharded(AsyncGroupByRecordCursorFactory.java:359) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursorFactory.aggregate(AsyncGroupByRecordCursorFactory.java:242) at io.questdb.cairo.sql.async.PageFrameReduceJob.reduce(PageFrameReduceJob.java:241) at io.questdb.cairo.sql.async.PageFrameReduceJob.consumeQueue(PageFrameReduceJob.java:189) at io.questdb.cairo.sql.async.PageFrameReduceJob.consumeQueue(PageFrameReduceJob.java:106) at io.questdb.cairo.sql.async.PageFrameSequence.stealWork(PageFrameSequence.java:574) at io.questdb.cairo.sql.async.PageFrameSequence.dispatch(PageFrameSequence.java:526) at io.questdb.cairo.sql.async.PageFrameSequence.next(PageFrameSequence.java:345) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.buildMap(AsyncGroupByRecordCursor.java:187) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.buildMapConditionally(AsyncGroupByRecordCursor.java:246) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.hasNext(AsyncGroupByRecordCursor.java:138) at io.questdb.griffin.engine.orderby.LongSortedLightRecordCursor.sortValues(LongSortedLightRecordCursor.java:179) at io.questdb.griffin.engine.orderby.LongSortedLightRecordCursor.hasNext(LongSortedLightRecordCursor.java:96) at io.questdb.griffin.engine.QueryProgress$RegisteredRecordCursor.hasNext(QueryProgress.java:419) at io.questdb.cairo.mv.MatViewRefreshJob.insertAsSelect(MatViewRefreshJob.java:472) at io.questdb.cairo.mv.MatViewRefreshJob.refreshIncremental0(MatViewRefreshJob.java:921) at io.questdb.cairo.mv.MatViewRefreshJob.refreshIncremental(MatViewRefreshJob.java:862) at io.questdb.cairo.mv.MatViewRefreshJob.incrementalRefresh(MatViewRefreshJob.java:403) at io.questdb.cairo.mv.MatViewRefreshJob.processNotifications(MatViewRefreshJob.java:645) at io.questdb.cairo.mv.MatViewRefreshJob.run(MatViewRefreshJob.java:120) at io.questdb.mp.Worker.run(Worker.java:152)
2025-05-29 10:27:04.411 EDT
, id=181, taskType=1, frameIndex=2092, frameCount=2166]
2025-05-29 10:27:04.413 EDT
2025-05-29T14:27:04.413491Z E i.q.c.s.a.PageFrameReduceJob reduce error [error=
2025-05-29 10:27:04.413 EDT
io.questdb.cairo.CairoException: [-1] global RSS memory limit exceeded [usage=40548381724, RSS_MEM_LIMIT=40587440940, size=67108864, memoryTag=29] at io.questdb.cairo.CairoException.instance(CairoException.java:370) at io.questdb.cairo.CairoException.nonCritical(CairoException.java:128) at io.questdb.std.Unsafe.checkAllocLimit(Unsafe.java:352) at io.questdb.std.Unsafe.realloc(Unsafe.java:280) at io.questdb.cairo.map.OrderedMap.resize(OrderedMap.java:591) at io.questdb.cairo.map.OrderedMap$Key.checkCapacity(OrderedMap.java:868) at io.questdb.cairo.map.OrderedMap$FixedSizeKey.init(OrderedMap.java:649) at io.questdb.cairo.map.OrderedMap$FixedSizeKey.init(OrderedMap.java:621) at io.questdb.cairo.map.OrderedMap.withKey(OrderedMap.java:388) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursorFactory.aggregateSharded(AsyncGroupByRecordCursorFactory.java:359) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursorFactory.aggregate(AsyncGroupByRecordCursorFactory.java:242) at io.questdb.cairo.sql.async.PageFrameReduceJob.reduce(PageFrameReduceJob.java:241) at io.questdb.cairo.sql.async.PageFrameReduceJob.consumeQueue(PageFrameReduceJob.java:189) at io.questdb.cairo.sql.async.PageFrameReduceJob.run(PageFrameReduceJob.java:150) at io.questdb.mp.Worker.run(Worker.java:152)
2025-05-29 10:27:04.413 EDT
, id=181, taskType=1, frameIndex=2091, frameCount=2166]
2025-05-29 10:27:06.529 EDT
2025-05-29T14:27:06.529508Z E i.q.g.e.QueryProgress err [id=5702, sql=`
2025-05-29 10:27:06.529 EDT
SELECT
2025-05-29 10:27:06.529 EDT
timestamp,
2025-05-29 10:27:06.529 EDT
asset,
2025-05-29 10:27:06.529 EDT
user,
2025-05-29 10:27:06.529 EDT
sum(amount_approx) as amount_approx,
2025-05-29 10:27:06.529 EDT
sum(amount_part1) AS amount_part1,
2025-05-29 10:27:06.529 EDT
sum(amount_part2) AS amount_part2,
2025-05-29 10:27:06.529 EDT
sum(amount_part3) AS amount_part3,
2025-05-29 10:27:06.529 EDT
sum(amount_part4) AS amount_part4,
2025-05-29 10:27:06.529 EDT
sum(amount_part5) AS amount_part5,
2025-05-29 10:27:06.529 EDT
sum(amount_part6) AS amount_part6,
2025-05-29 10:27:06.529 EDT
sum(amount_part7) AS amount_part7,
2025-05-29 10:27:06.529 EDT
sum(amount_part8) AS amount_part8
2025-05-29 10:27:06.529 EDT
FROM holdings_daily
2025-05-29 10:27:06.529 EDT
SAMPLE BY 1M
2025-05-29 10:27:06.529 EDT
`, principal=admin, cache=false, refreshMinTs=2024-07-01T00:00:00.000000Z, refreshMaxTs=2025-05-31T23:59:59.999999Z, jit=true, time=28941259832, msg=global RSS memory limit exceeded [usage=40548381724, RSS_MEM_LIMIT=40587440940, size=67108864, memoryTag=29], errno=-1, pos=0]
2025-05-29 10:27:06.529 EDT
2025-05-29T14:27:06.529765Z E i.q.c.m.MatViewRefreshJob could not refresh materialized view [view=holdings_monthly~509, ex=
2025-05-29 10:27:06.529 EDT
io.questdb.cairo.CairoException: [-1] global RSS memory limit exceeded [usage=40548381724, RSS_MEM_LIMIT=40587440940, size=67108864, memoryTag=29] at io.questdb.cairo.CairoException.instance(CairoException.java:370) at io.questdb.cairo.CairoException.nonCritical(CairoException.java:128) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.buildMap(AsyncGroupByRecordCursor.java:198) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.buildMapConditionally(AsyncGroupByRecordCursor.java:246) at io.questdb.griffin.engine.table.AsyncGroupByRecordCursor.hasNext(AsyncGroupByRecordCursor.java:138) at io.questdb.griffin.engine.orderby.LongSortedLightRecordCursor.sortValues(LongSortedLightRecordCursor.java:179) at io.questdb.griffin.engine.orderby.LongSortedLightRecordCursor.hasNext(LongSortedLightRecordCursor.java:96) at io.questdb.griffin.engine.QueryProgress$RegisteredRecordCursor.hasNext(QueryProgress.java:419) at io.questdb.cairo.mv.MatViewRefreshJob.insertAsSelect(MatViewRefreshJob.java:472) at io.questdb.cairo.mv.MatViewRefreshJob.refreshIncremental0(MatViewRefreshJob.java:921) at io.questdb.cairo.mv.MatViewRefreshJob.refreshIncremental(MatViewRefreshJob.java:862) at io.questdb.cairo.mv.MatViewRefreshJob.incrementalRefresh(MatViewRefreshJob.java:403) at io.questdb.cairo.mv.MatViewRefreshJob.processNotifications(MatViewRefreshJob.java:645) at io.questdb.cairo.mv.MatViewRefreshJob.run(MatViewRefreshJob.java:120) at io.questdb.mp.Worker.run(Worker.java:152)
2025-05-29 10:27:06.530 EDT
]

```

---

<div class="post-metadata">

**Author:** ![puzpuzpuz](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/puzpuzpuz/32/25_2.png) [@puzpuzpuz](https://community.questdb.com/u/puzpuzpuz)\
**Post date:** [May 30, 2025, 6:09am UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/26 "2025-05-30T06:09:45Z")

</div>

> The window didn’t change when changing to 10k (made sure the settings have been reloaded and applied)

This is very puzzling. I’ll try reproducing your partition layout locally to see what’s wrong.

In the meantime, could you try one more thing? Namely, could you disable parallel SQL execution in materialized view refresh? `cairo.mat.view.parallel.sql.enabled=false` - with this setting the query will run on a single thread, so that we properly handle OOM errors if they occur and retry with a smaller interval. Note: technically this should also work by default, in case of parallel SQL, but there is a bug around propagating OOM error between worker and main threads - we’ll fix it in the upcoming release.

---

<div class="post-metadata">

**Author:** ![JForsaken](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/jforsaken/32/398_2.png) [@JForsaken](https://community.questdb.com/u/JForsaken)\
**Post date:** [June 2, 2025, 7:38pm UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/27 "2025-06-02T19:38:07Z")

</div>

> [@puzpuzpuz](#):
>
> In the meantime, could you try one more thing? Namely, could you disable parallel SQL execution in materialized view refresh? `cairo.mat.view.parallel.sql.enabled=false` - with this setting the query will run on a single thread, so that we properly handle OOM errors if they occur and retry with a smaller interval. Note: technically this should also work by default, in case of parallel SQL, but there is a bug around propagating OOM error between worker and main threads - we’ll fix it in the upcoming release.

This worked! I was able to successfully run the MV sequence of deltas =\> hourly =\> daily =\> monthly successfully, having 500k as the estimate and `cairo.mat.view.parallel.sql.enabled=false` if this helps debug! Will monitor this thread to see when we can retry with parallelism, thanks again!

`select * from table_storage() where tableName ilike '%mv%';`

| tableName | walEnabled | partitionBy | partitionCount | rowCount | diskSize |
| --- | --- | --- | --- | --- | --- |
| mv\_month | true | MONTH | 12 | 71837449 | 10512077049 |
| mv\_day | true | DAY | 297 | 203203070 | 29512835061 |
| mv\_year | true | YEAR | 2 | 33158206 | 7132666053 |
| mv\_hourly | true | DAY | 298 | 237809285 | 34481490219 |

---

<div class="post-metadata">

**Author:** ![nwoolmer](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/nwoolmer/32/24_2.png) [@nwoolmer](https://community.questdb.com/u/nwoolmer)\
**Post date:** [June 2, 2025, 7:41pm UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/28 "2025-06-02T19:41:40Z")

</div>

Glad it is working!

The fix for the parallel OOM execution was merged: [fix(sql): unreliable out-of-memory error propagation in parallel SQL by puzpuzpuz · Pull Request #5711 · questdb/questdb · GitHub](https://github.com/questdb/questdb/pull/5711)

When the next version is released, you could revert that config and give it another go, just to confirm that the problem is fixed for next time.

---

<div class="post-metadata">

**Author:** ![JForsaken](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/jforsaken/32/398_2.png) [@JForsaken](https://community.questdb.com/u/JForsaken)\
**Post date:** [June 3, 2025, 6:42am UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/29 "2025-06-03T06:42:23Z")

</div>

nice thats was fast lol 🦾 Will be looking forward to bump to the next version when its out to try it out with parallelism!

---

<div class="post-metadata">

**Author:** ![nwoolmer](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.questdb.com/nwoolmer/32/24_2.png) [@nwoolmer](https://community.questdb.com/u/nwoolmer)\
**Post date:** [June 3, 2025, 6:42am UTC](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839/30 "2025-06-03T06:42:57Z")

</div>

It was, thanks to @puzpuzpuz 🙏!

[Previous page](https://community.questdb.com/t/using-a-materialized-view-as-another-materialized-view-as-base-timeout-oom/839.md?page=1)