News for hackers. Stuff that matters.

A comment on PostgreSQL: No More Vacuum, No More Bloat. Parent comment

Re:PostgreSQL: No More Vacuum, No More Bloat by glogla on Saturday July 15, 2023 @06:30PM (#36741531)
I'm pretty sure SQL Server and MySQL use locking instead of MultiVersion Concurrency Control so they don't keep more copies of data around. No vacuum needed but there's a possibility of things blocking.

But I might be out of date.

[ Parent | on HN ]
Re:PostgreSQL: No More Vacuum, No More Bloat by paulddraper on Saturday July 15, 2023 @06:50PM (#36741639)
Yes, MySQL has read locks.

But I don't believe SQL Server does.

[ Parent | on HN ]
Re:PostgreSQL: No More Vacuum, No More Bloat by evanelias on Saturday July 15, 2023 @06:51PM (#36741646)
InnoDB (MySQL's default storage engine) implements MVCC using undo logging and background purge threads. It scales to highly concurrent OLTP workloads quite well. It doesn't work well with OLAP workloads / long-running transactions though. The oldest active transaction will block purging of anything newer than that transaction's snapshot.
[ Parent | on HN ]
Re:PostgreSQL: No More Vacuum, No More Bloat by arbitrix on Saturday July 15, 2023 @07:04PM (#36741717)
SQL Server has had MVCC since 2005.
[ Parent | on HN ]
Re:PostgreSQL: No More Vacuum, No More Bloat by DaiPlusPlus on Saturday July 15, 2023 @09:03PM (#36742446)
Yes, but doesn't it require opt-in to enable snapshopt isolation? Most T-SQL devs will probably default to locking (TABLLOCK, etc) becuase that's what the bulk of google search results for "how do I fix my broken query?" tell people to do: it's only very, very rarely do I see a stackoverflow or dba.se answer that mentions MVCC-related topics.
[ Parent | on HN ]