Live data from Hacker News

PostgreSQL Rising

wekeroad.com

141–150 of 204 posts

Re: PostgreSQL Rising

#141
post #96
post #48

Earlier quoted context omitted.

wow, where to begin with the factual errors in this post - most of this post is incorrect. Just to get it out of the way, SQLAlchemy does not emit the "BEGIN" statement, nor does it call any kind of database function that directly emits "BEGIN", ever . Feel free to grep for it, start at version 0.1.0 and go all the way up to the 0.8 tip - you won't see it. It's not a default, it's nothing SQLAlchemy has any kind of o…

> To put it simply, VACUUM has no problems with connections being open. What you're thinking of here are locks, and locks only occur once you're in a transaction and have accessed some table rows, which are now subject to various isolation rules. I think you are correct except about this. What he is thinking about is indeed as he said transactions. Locks in PostgreSQL do also interfere with VACUUM but that is seldom…

thanks for the clarification. in practice, sure, we're all looking in our pg_stat_activity for "open in transaction" in general as something that shouldn't be hanging around.

Re: PostgreSQL Rising

#142
post #47

Earlier quoted context omitted.

I've never used PostgreSQL at my jobs outside of initial "could we switch" testing. I know of a couple of benefits that MySQL has/had over PostgreSQL. 1. The commands are very user friendly. In MySQL you can issue commands like "show tables" and "show databases". The last time I used PostgreSQL, the commands were much more esoteric. Things like "\dt". It adds a good hill to the learning curve 2. MySQL is everywhere .…

As for "show tables", there's a big difference here. "show tables;" is a server-side command. \dt is a command you give psql to say "ask the server what tables there are and list them." \d stands for describe. If you use a graphical client, it will have to query the system catalogs itself which you can do if you want. As for replication, the real challenge is that replication is not a one-size-fits-all thing. Slony,…

You're right. I didn't mean to imply that PostgreSQL didn't have much mindshare, it's obviously very popular and for good reason. MySQL is simply much more popular than that.

I've been able to look at PostgreSQL a few times over the years, and your right that the friendliness is getting better.

It's a very impressive system.

Re: PostgreSQL Rising

#143
post #84

The primary target audience for hacker-to-hacker Postgres evangelism is MySQL users. Because let's face it, the choice for DBs like Oracle is usually made upstairs, and for very different reasons. So why do Postgres advocates insist on dissing MySQL with false and misleading arguments? The usual target is some default settings, when obviously there are three kinds of MySQL users: the ones that actually have a reason…

I suspect the main reason for organisations running Oracle (and MS SQL Server) is because you want to run 3rd party applications.

That's one reason. The reason why they need it for third-party applications is because that's what developers targeted, for two reasons:

1. It was the only game in town when the application was designed.

2. It was head-and-shoulders above everyone else. More, better, faster. Most people think you just throw SQL-99 at it, but then you're wasting your money. Look at their analytical languages, for example.

Re: PostgreSQL Rising

#144

Earlier quoted context omitted.

I suspect the main reason for organisations running Oracle (and MS SQL Server) is because you want to run 3rd party applications.

That's one reason. The reason why they need it for third-party applications is because that's what developers targeted, for two reasons: 1. It was the only game in town when the application was designed. 2. It was head-and-shoulders above everyone else. More, better, faster. Most people think you just throw SQL-99 at it, but then you're wasting your money. Look at their analytical languages, for example.

Of course, Oracle and Microsoft are also major vendors of applications that run on their database servers. In fact, the application revenue for both is probably much higher than database server revenue.

Re: PostgreSQL Rising

#145
post #142

Earlier quoted context omitted.

As for "show tables", there's a big difference here. "show tables;" is a server-side command. \dt is a command you give psql to say "ask the server what tables there are and list them." \d stands for describe. If you use a graphical client, it will have to query the system catalogs itself which you can do if you want. As for replication, the real challenge is that replication is not a one-size-fits-all thing. Slony,…

You're right. I didn't mean to imply that PostgreSQL didn't have much mindshare, it's obviously very popular and for good reason. MySQL is simply much more popular than that. I've been able to look at PostgreSQL a few times over the years, and your right that the friendliness is getting better. It's a very impressive system.

I don;t know how you would measure popularity. I think it is fair to say that MySQL has more visible mindshare.

I guess if "popular" is a synonym for "demotic" (in the sense of progressing away from professional dba's etc) then MySQL is also more popular in that sense too. But in terms of actual mindshare, it is rediculously hard to compare them.

Re: PostgreSQL Rising

#146
post #129

Earlier quoted context omitted.

> MySQL is the storage platform for people who do not know about databases. Exactly. I mean seriously what do Facebook, Twitter, Yelp, LinkedIn, Flickr etc know about storing lots of data.

If FB or twitter miss a status update, it's no big deal. If you bank misses your salary going in, it is a HUGE deal. Use the right tool for the job.

And what about Amazon, Craigslist, eBay, Etsy, Google, Groupon, Ticketmaster, Yahoo etc.

You think they are equally going to be okay with losing data ? Or do you want to try again.

Re: PostgreSQL Rising

#147
post #3

The complaint that MySQL is by default loosey-goosey with your data is valid, but it's an easy default to change. Here is what happens when you run some of the commands shown in that 'Why Not MySQL?' video on a sanely configured MySQL system by setting SQL_MODE to TRADITIONAL. This mode also allows you to not have dates with zeroes, etc. mysql> alter table test change column my_money my_money decimal(2,0); Query OK,…

1) can applications set the SQL_MODE themselves? Can an admin configure the server so applications cannot specify mode? If not, what good is it since it won't guarantee your data? 2) My larger frustration with MySQL is I have run into cases of single transactions deadlocking against themselves. These always happen when the following is true: * Executing an insert statement in the form of INSERT foo (bar) VALUES (1),…

What version of MySQL? Sounds like the old AUTOINC lock mode behavior. http://insatiabledemand.ideeli.com/post/18850015294/diagnosi...

Re: PostgreSQL Rising

#148
post #129

Earlier quoted context omitted.

If FB or twitter miss a status update, it's no big deal. If you bank misses your salary going in, it is a HUGE deal. Use the right tool for the job.

And what about Amazon, Craigslist, eBay, Etsy, Google, Groupon, Ticketmaster, Yahoo etc. You think they are equally going to be okay with losing data ? Or do you want to try again.

Amazon runs its real-money handling on MySQL? Link please.

Re: PostgreSQL Rising

#149

I think the reason that MySQL became more popular than PostgreSQL is because it did one thing really good: It was a very fast file access daemon. PostgreSQL tried to do too much, ended up not doing any of it very well especially in the area of performance and didn't become as popular. Maybe useful to remember this going forward.

I see it as a major success story. Postgres was developed over a long period of time with careful attention to architecture, robustness, and extensibility. It also focused on both external and internal documentation and cleanliness . And, it followed the traditional database system model with a cost-based optimizer and everything else. As a result, we see a very robust developer community. It's a real machine -- chur…

Your entire argument falls apart when you look at all of the companies that chose MySQL over PostgreSQL and are still using them today. Basically every major internet site today relies on MySQL.

Re: PostgreSQL Rising

#150
post #33

Earlier quoted context omitted.

Definitely. When your application needs hundreds of read slaves in order to scale the load, PostgreSQL has always been everyone's first choice due to it's mature and historically awesome replication system. That's why companies who need to scale big (YouTube, Facebook, Yahoo, LinkedIn, Wikipedia, Twitter etc) all have hundreds (if not thousands) of PostgreSQL machines in their infrastructure.

Im going to assume this is sarcasm since Facebook is built entirely on sharded MySQL. Don't want anyone else to get confused in case it doesn't come through for them.

Facebook, et al, use memcache and a plethora of other products to improve the scalability of MySQL. Here's one scalability comparison between the two: http://tweakers.net/reviews/649/7
Post reply on HN