A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

Don't do the crime, if you can't do the time.

-- Anthony Vincenzo "Tony" Baretta

Vim is an amazing text editor. I love it. Really, I wouldn't [organize][organize] a Vim advent calendar if I didn't. But, as amazing as it is, Vim is not for everyone. It can't solve all your problems, or be a TUI version of your favorite IDE, or make you a better programmer, or land you that dream job in the Bay Area. But Vim can help you be more mindful, focused, and efficient, as long as you approach it with the right mindset.

Don't get me wrong, I certainly welcome you to try Vim, but I'm not a proselyte. I don't thrive on newbies. I just want you to use the right tool for the job and not waste your—and anyone's—time on a fruitless quest.

Many developers assume PostgreSQL materialized views handle incremental updates out of the box. They do not. If you have a materialized view with millions of rows and a single underlying record changes, both native refresh options process the entire dataset.

Because of this limitation, anyone needing immediate maintenance or working with large datasets must abandon materialized views entirely. The standard workaround is to manually maintain a standard table using custom database triggers or application logic.

I've been working on a patch to fix this. It adds an optional WHERE clause to the REFRESH MATERIALIZED VIEW command, letting you scope a refresh to exactly the rows that changed. The patch is currently under review on the pgsql-hackers mailing list.

The only requirement for this approach is that the materialized view must have a unique index (the same requirement as REFRESH MATERIALIZED VIEW ... CONCURRENTLY).

It al