Earlier quoted context omitted.
Also, I'm pretty sure most of us are mispronouncing MySQL: IIRC, "My" (the Finnish name of his daughter) is pronounced like English "Me".
The y is pronounced like the ü in über.
"MooSQL"
Why we lost Uber as a user
201–210 of 310 posts
Re: Why we lost Uber as a user
#202The PoststgreSQL project never fails to impress me. I know that there are some use cases which are not currently covered by it versus alternatives, but I have consistently got the feeling that everybody involved in the project is supremely professional and interested in building an excellent database – and the focus is on how to work to fix these use cases, instead of pointless mudslinging. Class act.
> The PoststgreSQL project never fails to impress me. Except the name is a bit clunky and hard to write ;)
Too bad they didn't name it something non-controversial like cockroach.
Re: Why we lost Uber as a user
#203Earlier quoted context omitted.
A small bit of history from Tom Lane one of the biggest contributors to the project "Arguably, the 1996 decision to call it PostgreSQL instead of reverting to plain Postgres was the single worst mistake this project ever made." - https://www.postgresql.org/message-id/2693.1152762174@sss.pg...
> It seems too late to change it now That's what they said in 1996. Then they said it again in 2006. In 2026 when its interwoven in all sorts of AI systems and still causing confusion, they will be looking back thinking why didn't they fix it back in 2017 when they still could. "Now" is always the right time, it's never too late.
“The best time to plant a tree was 20 years ago. The second best time is now.” – Chinese Proverb
Re: Why we lost Uber as a user
#204Earlier quoted context omitted.
If only a clunky name was the worst problem with some software (even closed source) we have to deal with.
Slightly clunky names are fine as long as they're somewhat cute or clever. Names are important because it's how we identify and remember things, and a catchy name (even if it seems a little ridiculous or clunky) is better than a boring, banal name if the catchy name is memorable. I'll take PostgreSQL's name (which I consider clever) any day over some name completely devoid of originality or thoughtfulness, such as mo…
Microsoft's naming (or lack of) is a mixed blessing.. usually combining "Microsoft" + term works... what sucks is when you search for anything "SQL" and you get a bunch of MS-SQL related links... really, T-SQL and MS-SQL should always be prefixed when referring to the vendor's product.
Re: Why we lost Uber as a user
#205Earlier quoted context omitted.
> The PoststgreSQL project never fails to impress me. Except the name is a bit clunky and hard to write ;)
> The PostststgreSQL project never fails to impress me. Let's see how many iterations we'll need for people to actually notice what was pointed out here ;)
[deleted]
Re: Why we lost Uber as a user
#206Earlier quoted context omitted.
Reddit styles puns aren't allowed here, that's why you're getting downvoted.
what an enlightened community of robot people
You misspelt "people who like intelligent discussion". A joke now and then is okay, but try to give it enough redeeming value. (And for the rest, don't worry too much about downvotes.)
Re: Why we lost Uber as a user
#207Re: Why we lost Uber as a user
#208great explanation by the Postgres crew. it makes me wonder, though: if I had a table with 50k rows, updated hundreds of times per second and used in joins throughout the database, is there any way I can just stick that whole table into memcached or redis? I know there are some cases where this works, some where it doesn't. curious if this option was explored.
Completely agreee. Highly mutable => in memory ( then add a secondary stream for colder storage backups just in case). A relational db is originaly meant for fetching data from a slow storage to a fast one, and the other way around, in a smart way. Doing it 500 times a second isn't a scenario for any db. Build your own in memory data + process tructure, maybe using something like and agent network and using eg akka o…
It's often simpler to keep data in a relational DB for reporting, especially if you've got data lake tooling -- it's just easier to get wider insights if your data is stored relationally. I know it's possible to do this without relational DB, but you get it for free with SQL.
As you say though, put it in memory first and write it out to a DB every now and then.
Re: Why we lost Uber as a user
#209This might explain a lot of the performance problems we've seen trying to use Postgresql as an event store, dumping some 10s of millions of rows/day into a table that has a few indexes (no foreign keys, but trying to speed up queries). Sounds like it's time to investigate alternatives.
I would think it's unrelated. The issue described by Uber and the Postgres team is specifically related to UPDATEs against highly indexed tables. In an event store the data is typically completely immutable.
Re: Why we lost Uber as a user
#210Earlier quoted context omitted.
The design of MySQL has a lot more silent failures, silent coercing of data, and other ways that it attempts to do what it thinks you might mean (because you're an incompetent PHP programmer) instead of what you ask. The obvious example is that SELECT 0 = 'banana' returns 1. A typical takedown would be the likes of: http://grimoire.ca/mysql/choose-something-else (which also touches storage engine configuration things…
I'm pretty sure Uber has enough money and enough developers to configure MySQL to not do any of that.
You can't configure MySQL to not do "any" of that. You can certainly make it better, but there simply aren't options to configure away all of the boneheadedness.
There are also tons of hidden gotchas that exist in, for example, the query planner. It can be extremely fickle and suddenly switch from a performant query plan to a terrible one that creates unindexed temporary tables and sorts them or joins against them. Or just ignores relevant indexes in the tables whatsoever.
Everything hums along fine until a random INSERT or UPDATE causes the query plan to change, bringing down your entire site. To be fair, such a problem can happen in any DBMS but I've never experienced it with Postgres to the extent that I have with MySQL.