16 comments

[ 0.22 ms ] story [ 46.2 ms ] thread
> With PostgreSQL 14 released just a few weeks ago...

Would benefit from putting "2021" in the title

(comment deleted)
(comment deleted)
I'd probably love to have the "REFRESH ON COMMIT"-feature for materialized views, to refresh (only the) impacted rows automatically whenever rows of the source table(s) change :)

(the same like in Oracle - https://docs.oracle.com/en/database/oracle/oracle-database/1... - but I would not need the fancy "query rewrite" feature that make SQLs use the matView even if they don't explicitly mention it in their SQL)

"Incremental view maintenance"

Lots and lots of theory about how to do this correctly.

I authored a project to do this with triggers. https://github.com/rivethealth/denorm

Nice! I did this "by hand" for a dozen views a few years back, fiddly but rewarding; if I have to do it again ...
We've had success using DBT incremental models for this. Deletes aren't supported though, but for our use case that's fine and do a nighly refresh on the whole.

Otherwise the best alternative would be something like https://materialize.com

There are a few nice things in that, like (x, y) IN (SELECT ...), ROW_NUMBER() OVER (PARTITION BY ...), and (start1, end1) OVERLAPS (start2, end2).
I discovered `\crosstabview` the other day! It does, of course, use crosstab underneath. It's just some psql magic.

One tiny thing I discovered which I use a surprising amount is `table <tablename>;` is equivalent to `select * from <tablename>;`.

I bet that the `watch` feature would make to the list if the article was written these days.

`watch` is the coolest Postgres feature that I've discovered recently.