Forum Discussion
Notebook delta table merge operation error: Cannot seek after EOF
Does it work if you automate the table maintenance?
E.g. by scheduling a Notebook to run OPTIMIZE on the tables at a pre-defined interval?
Hi frithjof_v , Thanks for the suggestion. Yes, that's a good idea. I've implemented a table maintenance notebook that does this. However, it's difficult to determine when an optimize needs to happen. I had now done it when the last optimize was more than 7 days ago. however, sometimes I run into this issue less than a day after the previous time. So, do I need to schedule the table maintenance twice a day? That sounds like a lot of overhead and just not right. It's pretty frustrating to open the monitor every morning and find that jobs have failed again because of this issue...
- frithjof_v1 year agoCommunity Champion
To be honest I don't have too much practical experience with it.
How often is the merge operation running?
(I'm wondering how often data is added/changed in your delta table)
- ntimmerman1 year agoHelper I
- frithjof_v1 year agoCommunity Champion
I'm surprised you get that error.
In general, the more often you update the data, especially inserts, it makes sense to regularly optimize the table to rearrange (compact) the underlying parquet files.
But only updating the data 8 times a day, I would assume running optimize 1 time daily would be sufficient to get good performance.
Have you got any measurements on how costly the optimize operation is? If it's cheap, it doesn't hurt to run it more often. But I would expect running optimize 1 time daily to be more than enough when you update data 8 times daily. So I think it's strange to get an error in this case.
Have you got partitions on the table (this could cause some performance issues especially if you have partitions on high-cardinality columns).
Btw, the error message mentions stage failure. I have no idea what it means. But would it help to first land the new data in a staging delta table, and then merge the staged data into the destination table? Although that wouldn't explain why running maintenance on the destination table seems to help in your case.
I'm not sure what the underlying issue here really is.