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

The part of Postgres we hate the most: Multi-version concurrency control

ottertune.com

Post reply on HN
Print view View original

51–60 of 148 posts

Re: The part of Postgres we hate the most: Multi-version concurrency control

#51

Post by dang »

eduction wrote: post #46
dang wrote: post #22

Earlier quoted context omitted.

I asked them to take that bit out at the end and it looks like they did. General remark for startups wanting attention on HN: it's not good to end an interesting article with a call-to-action that makes your article feel like an ad. Readers who read to the end experience that as a bait-and-switch and end up feeling betrayed. What works much better is to disclose right up front what your startup is and how it's relate…

I think it’s disturbing you asked someone to change their content and even more disturbing that they complied. You are experienced at moderating Havker News have no business being a global censor for content out in the world. This sucks. As a reader I’d have appreciated the original. And I’d appreciate a nice HN alternative.

Perhaps I should explain. What I actually did was suggest that it would be in their interest to take out the bit that some readers were complaining about, because it felt like an ad at the end. Of course they were free not to follow my suggestion.

I admit that's not precisely how I described it in the GP comment but it never crossed my mind that anyone would care. Commenter objections never fail to surprise!

Edit: I think I was right that it was in their interest as well as all of ours, because earlier the thread was dominated by complaints like this:

https://news.ycombinator.com/item?id=35718321

https://news.ycombinator.com/item?id=35718172

... and after the change, it has been filling up with much more interesting on-topic comments. From my perspective that's a win-win-win, but YMMV.

Re: The part of Postgres we hate the most: Multi-version concurrency control

#52

Post by vore »

eduction wrote: post #46
dang wrote: post #22

Earlier quoted context omitted.

I asked them to take that bit out at the end and it looks like they did. General remark for startups wanting attention on HN: it's not good to end an interesting article with a call-to-action that makes your article feel like an ad. Readers who read to the end experience that as a bait-and-switch and end up feeling betrayed. What works much better is to disclose right up front what your startup is and how it's relate…

I think it’s disturbing you asked someone to change their content and even more disturbing that they complied. You are experienced at moderating Havker News have no business being a global censor for content out in the world. This sucks. As a reader I’d have appreciated the original. And I’d appreciate a nice HN alternative.

Even if they decided not to change it which is fully within their rights and somehow that gets the article moderated off the front page of Hacker News, isn't that still moderating Hacker News? No one is getting censored, just like nobody is entitled to have their article be on Hacker News.

Re: The part of Postgres we hate the most: Multi-version concurrency control

#53

Post by osigurdson »

cyberax wrote: post #30

Yup. A lot of heavy users of Postgres eventually hit the same barrier. Here's another take from Uber: https://www.uber.com/blog/postgres-to-mysql-migration/ I had a similar personal experience. In my previous job we used Postgres to implement a task queuing system, and it created a major bottleneck, resulting in tons of concurrency failures and bloat. And most dangerously, the system failed catastrophically under loa…

>> In my previous job we used Postgres to implement a task queuing system, and it created a major bottleneck, resulting in tons of concurrency failures and bloat

Yet, every month or two an article about doing exactly this is upvoted to near the top of HN. It can of course work but might hard to replace years later once "barnacles" have grown on it. Every situation is different of course.

Re: The part of Postgres we hate the most: Multi-version concurrency control

#54

Post by jaggederest »

fovc wrote: post #28
h1fra wrote: post #23

Once you figured out all the point in this article, it's a matter of fine tuning, can take some times but eventually it will works. The only thing I still struggle with is the Table Bloat. On managed Postgres (i.e: gcp, aws) you pay for the disk, but when you can't run a VACUUM FULL because it locks the table, you end up with a lot of allocated storage for nothing and you can't shrink the disk size (at least on gcp).…

https://reorg.github.io/pg_repack/ Dead easy to run and no long-held locks

Absolutely critical once you get above a certain table size.

Re: The part of Postgres we hate the most: Multi-version concurrency control

#55

Post by pier25 »

mmaunder wrote: post #12

I must admit as a web practitioner since 1994 I have a bit of an issue with this: > In the 2000s, the conventional wisdom selected MySQL because rising tech stars like Google and Facebook were using it. Then in the 2010s, it was MongoDB because non-durable writes made it “webscale“. In the last five years, PostgreSQL has become the Internet’s darling DBMS. And for good reasons! Different DB's, different strengths and…

> MongoDB gained traction not because it's an alternative to MySQL or PostgreSQL.

Honestly I think it only gained traction because many Node devs refused to learn SQL and the document model is familiar because it's closer to JSON data.

These days Mongo is good but that wasn't the case back 10+ years ago.

Re: The part of Postgres we hate the most: Multi-version concurrency control

#56

Post by jasonwatkinspdx »

p_l wrote: post #43
mmaunder wrote: post #12

I must admit as a web practitioner since 1994 I have a bit of an issue with this: > In the 2000s, the conventional wisdom selected MySQL because rising tech stars like Google and Facebook were using it. Then in the 2010s, it was MongoDB because non-durable writes made it “webscale“. In the last five years, PostgreSQL has become the Internet’s darling DBMS. And for good reasons! Different DB's, different strengths and…

A non-trivial component to MySQL popularity was that easy installation (not necessarily administration) and comparatively low resource usage with good performance at default settings (even today one needs to run some basic calculations for postgres in production, IMO) meant that cheapest possible dynamic hosting using Linux, Apache, PHP3, and MySQL 3, was what simply was the only available option for many. This codif…

Another factor besides performance vs earlier versions of Postgres (they're now more at parity) was Postgres didn't come with replication included. I think that was a big hinderance for adoption during the LAMP stack's hey day.

Re: The part of Postgres we hate the most: Multi-version concurrency control

#57

Post by p_l »

hodgesrm wrote: post #48
mmaunder wrote: post #12

I must admit as a web practitioner since 1994 I have a bit of an issue with this: > In the 2000s, the conventional wisdom selected MySQL because rising tech stars like Google and Facebook were using it. Then in the 2010s, it was MongoDB because non-durable writes made it “webscale“. In the last five years, PostgreSQL has become the Internet’s darling DBMS. And for good reasons! Different DB's, different strengths and…

> A non-trivial component to MySQL popularity was that easy installation ...Along with replication and being joined with the hip to PHP. As to installation, there was a point in time in the early 2000s where you could sudo to root, type 'mysql' and be talking to a live MySQL on most Linux distros that I used. No wonder a lot of people defaulted to it.

Replication came later - but the fact that you could do

  sudo apt-get install mysql-server mysql-client
  sudo -i mysql
and be logged in as admin into mysql database was indeed a huge reason for defaulting to it.

EDIT: Of course, at that time, there was no Ubuntu teaching everyone to sudo all the time, so drop all instances of sudo and add a su - at start ;)

Re: The part of Postgres we hate the most: Multi-version concurrency control

#58

Post by thinkx »

fdr wrote: post #39

One of the weird things about Postgres MVCC is that it is "optimized for rollback," as one person memorably quipped to me. This is not to imply a design principle, it's more a description of how things ended up, and the general argument behind this quip is Postgres lacks "UNDO" segments. On the one hand, this does make the model Postgres uses admirably simple: the WAL is all "REDO," and the heap is all you need to ac…

Coming to Postgres, UNDO logs and no vacuum

https://github.com/orioledb/

Re: The part of Postgres we hate the most: Multi-version concurrency control

#59

Post by p_l »

jasonwatkinspdx wrote: post #56
p_l wrote: post #43

Earlier quoted context omitted.

A non-trivial component to MySQL popularity was that easy installation (not necessarily administration) and comparatively low resource usage with good performance at default settings (even today one needs to run some basic calculations for postgres in production, IMO) meant that cheapest possible dynamic hosting using Linux, Apache, PHP3, and MySQL 3, was what simply was the only available option for many. This codif…

Another factor besides performance vs earlier versions of Postgres (they're now more at parity) was Postgres didn't come with replication included. I think that was a big hinderance for adoption during the LAMP stack's hey day.

Honestly, at the time when LAMP was gaining the userbase, said userbase for considerable portion did not care about replication because there was only one server they had.

Replication was something you did when you got succesful enough to have it, or were a MSP providing it at premium to others.

Re: The part of Postgres we hate the most: Multi-version concurrency control

#60

Post by guywhocodes »

osigurdson wrote: post #53
cyberax wrote: post #30

Yup. A lot of heavy users of Postgres eventually hit the same barrier. Here's another take from Uber: https://www.uber.com/blog/postgres-to-mysql-migration/ I had a similar personal experience. In my previous job we used Postgres to implement a task queuing system, and it created a major bottleneck, resulting in tons of concurrency failures and bloat. And most dangerously, the system failed catastrophically under loa…

>> In my previous job we used Postgres to implement a task queuing system, and it created a major bottleneck, resulting in tons of concurrency failures and bloat Yet, every month or two an article about doing exactly this is upvoted to near the top of HN. It can of course work but might hard to replace years later once "barnacles" have grown on it. Every situation is different of course.

I've built this queue system probably 5 times, first 2-3 were failures as consumer concurrency was 1 without us noticing for hours. The bloat comes from updating the work instead of deleting I assume, did for me. There are definitely many ways to not do it right but kinda works.
Post reply on HN