Every commit on any table the view depends on will update the materialized view. In Oracle you can just “CREATE MATERIALIZED VIEW refresh fast on commit as ” and that’s it - Oracle will take care of the rest. Say you have an aggregate or join that executes very frequently. I can list off of the top of my head a number of capabilities Oracle has had for almost 20 years that PG either doesn’t have or just might have in the near future:ġ On commit fast-refresh materialized views Putting aside the usual issues of bugs and related incidents (both have had their fair share), the Oracle Database is a technological marvel. Only the F-22 can also transform into a Super Hercules and a helicopter. Having said all that, and coming from many years of experience as both an Oracle DBA and PG DBA - comparing Oracle Database to Postgresql is almost like comparing a Cessna to an F-22. It should also be said that Oracle’s products are insanely expensive, and yes, their business practices have been called into question quite a few times in the past. Many owe a debt of gratitude to the creators and maintainers of PG. It has earned its respect many times over. Also, countless organizations have used it with much success.
PGADMIN 4 ER DIAGRAM CODE
Due to its permissive license, parts of its source code served as the starting point for numerous database products, including Vertica, GreenPlum, and many more. It is without a doubt the best documented code base I have ever seen. Before I start, a disclaimer: I ❤ Postgres, I’ve been a PG Applicative DBA for the better part of the last decade, and as a programmer I absolutely love the PG code base.
0 kommentar(er)
