[pestaa]

Very impressive changelog.

Bit sad the UUIDv7 PR didn't make the cut just yet:

https://commitfest.postgresql.org/49/4388/

[ellisv]

I've been waiting for "incremental view maintenance" (i.e. incremental updates for materialized views) but it looks like it's still a few years out.

[JamesSwift]

I'm a huge fan of views to serve as the v1 solution for problems before we need to optimize our approach, and this is the main thing that serves as a blocker in those discussions. If only we were able to have v2 of the approach be an IVM-view, we could leverage them much more widely.

[whitepoplar]

There's always the pg_ivm extension you can use in the meantime: https://github.com/sraoss/pg_ivm

[ellisv]

Unfortunately we use a cloud provider to host our databases, so I can only install limited extensions.

[gregwebs]

REFRESH CONCURRENTLY is already an incremental update of sorts although you still pay the price of running a full query.

[isoprophlex]

Wow, brilliant! I never knew this existed. Going to try this out tomorrow, first thing!

[garyclarke27]

Agreed big disappointment that "incremental view maintenance" is taking so long to get into the core - despite several IVM extensions. For me this is by far the most important capability missing from Postgres.

[0cf8612b2e1e]

I must be missing something because that feels easy to implement. A date seconds + random data in the same way as UUID4.

Where is the iceberg complexity?

[lfittl]

In my understanding it was a timing issue with the UUIDv7 RFC not being finalized before the Postgres 17 feature freeze in early April. Shouldn't be an issue to get this in for Postgres 18, I think.

[0cf8612b2e1e]

That would do it. I was mistakenly thinking v7 was done for months/years at this point.

[Meniceses]

My assumption is that because you can easily do this through software when using UUID and probably a lot do it like this, the pressure of supporting it, is a lot lower than expected.