A reverse engineer friend once taught me I could patch an x86 function with `0xEBFE` to get the CPU to spin forever. It wasn’t until much later that I understood that (IIRC) 0xEB is the “single byte” jump instruction and that of course 0xFE is -1 as a signed byte. Hence the spin.
Even cooler, let's say you need to "update" a subset of your parquet files after they are written. Once you have your parquet files in a ducklake, you can "virtually" update them (the files themselves aren't touched, just new ones created). Something like:
- create your frozen ducklake
- run whatever "normal" mutation query you want to run (DELETE, UPDATE, MERGE INTO)
- use `ducklake_rewrite_data_files` to make new files w/ mutations applied, then optionally run `ducklake_merge_adjacent_files` to compact the files as well (though this might cause all files to change).
- call `ducklake_list_files` to get the new set of active files.
- update your upstream "source of truth" with this new list, optionally deleting any files no longer referenced.
The net result should be that any files "touched" by your updates will have new updated versions alongside them, while any that were unchanged should just be returned in the list files operation as is.
Not that I expect them to fix it at this point since it seems to be a known issue, but just in case anyone from Notion is watching please fix the macOS app’s CPU usage. On a brand new M3 MacBook Pro each tab takes about 10% of one core _non-stop_ even in the background. I have to constantly cull tabs or my machine becomes noticeably less responsive.