News for hackers. Stuff that matters.
Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by kstrauser on Thursday January 13, 2022 @03:46PM (#29926598)
Last I heard, it's the opposite: MySQL/MariaDB might be faster for single connections, but PostgreSQL can be much faster for heavy workloads. For instance, PostgreSQL added a feature to support sharing table scans between multiple connections. Suppose you have a million rows in a table "foo".

- Connection 1 executes "select * from foo". It begins at row 1 and starts a table scan.

- When the reader is at row 500,000, connection 2 executes "select * from foo". It starts returning results beginning at row 500,000, so both connections are sharing the output of the reader.

- When the reader gets to row 1,000,000, the first query is finished. It's seen all the rows. The reader starts back at row 1, and continues feeding results to the second query until it gets back to run 499,999. Then the second query is also finished.

Even though 2 queries were running, the DB backend was only doing the work of 1. With that setup, you could have 100 "select * from foo" queries running simultaneously without increasing the database load at all.

I don't know if MySQL supports that kind of thing now. In any case, that's an example of some of the incredible engineering PostgreSQL uses to be correct and fast.

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by CRConrad on Friday January 21, 2022 @11:26AM (#30025780)
Even though 2 queries were running, the DB backend was only doing the work of 1.

Well, one and a half. Or the work of one query, but one and a half times.

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by isotopp on Friday January 14, 2022 @01:49PM (#29938458)
If, in a customer facing database, you have to table scan, you have already lost.

For data warehouses this is a different story, but god help you if you are table scanning in OLTP context.