Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why PostgreSQL is better than MySQL

blog.2ndquadrant.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Why PostgreSQL is better than MySQL

#91

Post by pgaddict »

pizza234 wrote: post #55
icebraining wrote: post #40

Earlier quoted context omitted.

Just look back at how long it too for us to get upsert, we're finally getting a better replication story in recent years. Coincidentally, using those two features together on MySQL can have fun results: "Because the results of INSERT ... SELECT statements depend on the ordering of rows from the SELECT and this order cannot always be guaranteed, it is possible when logging INSERT ... SELECT ON DUPLICATE KEY UPDATE sta…

You're wrong, and interestingly, you're omitting the key part: > Such statements produce a warning in the error log when using statement-based mode and are written to the binary log using the row-based format when using MIXED mode The problem you're writing about is not related to MySQL itself, it's a problem implicit in statement-based replication. Row/mixed mode replication has been available in MySQL since 5.1 (al…

> DBAs must know how replication works, as RDBMSs are not toys. It's naive to think that replication in other RDBMs itjustworks! - see, for example, the replication bug that caused slave corruption to the famous transportation company.

I assume you mean Uber, and the replication bug they ran into on 9.2. Isn't it a bit strange comparing a bug (that got fixed promptly after it was reported) to implementing inherently unsafe replication mode?

Re: Why PostgreSQL is better than MySQL

#92

Post by pmarreck »

fgonzag wrote: post #82
pmarreck wrote: post #61

Earlier quoted context omitted.

So why is replication necessary?

HA, Read load balancing for a simple master-slave setup.

Back in my SQL Server days they had something called "log shipping" which is basically sending the transaction log over the wire to another machine where it is re-run. Does that still exist?

EDIT: It turns out there is https://www.postgresql.org/docs/9.1/static/warm-standby.html and this seems to accomplish the same goal without actually being replication, so what gives?

Re: Why PostgreSQL is better than MySQL

#93

Post by icebraining »

pizza234 wrote: post #88
icebraining wrote: post #72

Earlier quoted context omitted.

You do realize that I didn't write "insanity", right? All I said is "can have fun results". In any case, there are two issues described in my post.

Apologies if I confusingly replied to two posts in one, but there is common thread between the two, that is, a judgement on a product/feature, based on a radically uninformed knowledge of the subject. I've spent a few minutes after a Google search; results follow. Bug #11765650: this was fixed 5 and half years ago; see https://lists.mysql.com/commits/143383 ; Bug #58637: see https://bugs.mysql.com/bug.php?id=58637 -…

If users insist? Statement-based replication remained the default until 2015, full five years after the bug was reported.

Even today, the "16.2.1 Replication Formats" page says nothing about it being obsolete, or provide indication of level of danger in choosing it. It's like walking on a minefield where the markers are camouflaged.

Re: Why PostgreSQL is better than MySQL

#94

Post by pitaj »

pgaddict wrote: post #11
geofft wrote: post #5

Earlier quoted context omitted.

2nd Quadrant is a DBA-as-a-service company that does only Postgres, so it makes sense that the target audience is decision-makers trying to pick between databases who are themselves not DBAs (but probably in the position of hiring DBAs, either as normal employees or as a company to contract with).

FWIW we're not "DBA-as-a-service company". It's part of the job, but we do all sorts of stuff (support, consulting, trainings, custom development, ...)

You just explained what I'd say is the normal set of services associated with a XaaS provider.

Re: Why PostgreSQL is better than MySQL

#95

Post by tapoxi »

pmarreck wrote: post #92
fgonzag wrote: post #82

Earlier quoted context omitted.

HA, Read load balancing for a simple master-slave setup.

Back in my SQL Server days they had something called "log shipping" which is basically sending the transaction log over the wire to another machine where it is re-run. Does that still exist? EDIT: It turns out there is https://www.postgresql.org/docs/9.1/static/warm-standby.html and this seems to accomplish the same goal without actually being replication, so what gives?

I think warm standby is a relatively new feature for Postgres.

As someone who's had to configure warm standby recently, it's fine, but it's not active-active, which infuriated a few Oracle DBA colleagues. The best way to do that at the moment is by using a proxy like PgPool II.

Re: Why PostgreSQL is better than MySQL

#96

Post by oskari »

tbrock wrote: post #58
zeroxfe wrote: post #57

Earlier quoted context omitted.

I'm a Postgres fan too, and I remember this -- it really sucked. I loved Postgres, but setting up replication with it was basically duct-tape and string. Not to derail the thread too much, but this is exactly what's going on with Go and generics right now (and I'm a Go fan too.) "Why do you need generics?" "Generics don't solve all your problems" "Generics don't work well" "No language does generics perfectly".

This only changed very recently. The replication story for postgres has been a joke for over a decade and most people won’t run 9 or 10 for a while.

PostgreSQL has had native replication support since version 9.0 which was released in September 2010.

Re: Why PostgreSQL is better than MySQL

#97

Post by cbsmith »

leetrout wrote: post #47
cbsmith wrote: post #39

Earlier quoted context omitted.

Meh. It works both ways. There was a time if you asked for transactions on MySQL...

And I still don't have my DDL transactions... :) ;)

Yeah. I built out a whole framework to get around the DDL thing. Super annoying.

Re: Why PostgreSQL is better than MySQL

#98

Post by rompompel »

if you're not keeping score you're only practicing

So the main point why postgres is better is that they don't use a bug-tracking system? Definitely that makes any qualified comparison impossible of such claims as the better "time to fix" or bug responsiveness. IMHO this post is trying to sell a weakness as a strength.

Re: Why PostgreSQL is better than MySQL

#99

Post by manigandham »

rosser wrote: post #71
danudey wrote: post #38

Earlier quoted context omitted.

I remember ages ago (a decade? or so?) I started working at a company using Postgres for a project, and one of the things my boss asked me to do was to set up replication for the database. We had it on all of our MySQL databases, and everyone knew (myself included) that Postgres was a more serious, enterprise-y, "real" database. Well, I googled around and couldn't find anything conclusive, so I hopped into the / chan…

And it was the community that drew me in. Very early in my database career, I was having massive performance problems with my postgres install. I sent a very sharply toned message to the postgres performance mailing list. Within hours of that message, I was trading stack traces with Tom Lane . He was under no obligation to help me; in fact, I was, in hindsight, kinda a dick about it. But he did. You probably can't bu…

> You probably can't buy support of that caliber, no matter how much money you throw at it.

You're underestimating how good support can be. Postgres doesn't actually have a primary sponsoring company so good (and equivalent) talent is widely available from multiple vendors.

Re: Why PostgreSQL is better than MySQL

#100

Post by tatersolid »

zilchers wrote: post #68

Is it just me, or was that huge bug with serious implications if you don’t know it exists? I don’t often use MySQL, maybe its well know in the community.

I agree. Basically makes MySQL useless for a ton of application (data warehousing comes to mind).

I wonder how many private forks of MySQL had fixed that and never upstreamed a patch.

Post reply on HN