[tibiapejagala]

I haven't read the source code, but how does it handle materialized views? Views refer to source tables by relation id, not by name, so by default you end up with views pointing to old tables, which also means can't drop them.

My use case is somewhat different. I have ~400M row tables which are not updated live, but I rebuild them from new source data, because it is faster that way (lots of columns, indices and FKs). There are also materialized views based on these tables, similarly with multiple indices.

I wrote some sql scripts using information_schema, which prepare new tables for data import, rebuild indices, FKs and then swap tables. After that scripts recreate materialized views from definitions and swap them. All happens without ACCESS EXCLUSIVE lock, so it can be still used by the backend. It sucks, though. I wouldn't mind if there was a way to have views use table names, so I could just refresh them after swapping tables.

[shayonj]

Very interesting. Just so I understand - are you asking how does pg-osc updates the references in view(s) when pg-osc performs an ALTER on a table that is being referred in these view(s)?

If so, it actually doesn't handle that currently since AFAIK, there is no good way to get the views up w/o dropping and creating the view again :(.

[tibiapejagala]

Yes, I was a bit unclear, but that was my question exactly. I hoped that there is some trick I don’t yet know. Dropping and creating these massive views is my nightmare.