5 ms·

I'm not sure where this mantra that pgsql is slow comes from. My sense is it's more from the monolithic nature of a typical install which makes it difficult to

by bigdubs 11y ago

I'm not sure where this mantra that pgsql is slow comes from. My sense is it's more from the monolithic nature of a typical install which makes it difficult to scale horizontally to handle supreme amounts of load. For most development use cases, and even most production use cases, pgsql is plenty fast for almost everything if you design your schema well and leverage things like indexes.

ubercore 11y ago
I think the impression lingers from the early days when MySQL with myisam was the scaling "secret sauce" for everyone, because it leaves behind so many features. I don't know that MySQL was ever significantly faster after InnoDB became the engine most people used.
- davidw 11y ago
  Mysql was fast in the same way that a bicycle going down a hill without brakes is 'fast'.
  - meritt 11y ago
    You understand this is the sort of ignorant rhetoric that leads to the OP's post, right? InnoDB has been available for years and has been the default storage engine for nearly 6 years. Maria and Percona both default to XtraDB. The vast majority of MySQL criticisms haven't been valid for nearly a decade.
    - davidw 11y ago
      You understand "was", don't you? Mysql really took hold around 2000. Postgres was a perfectly valid option back then, too, but... "fast!". InnoDB still doesn't do DDL transactions, does it? That said, clearly Mysql has gotten more robust and Postgres faster.
rdtsc 11y ago
> I'm not sure where this mantra that pgsql is slow comes from. MongoDB factor is probably why from a few years back. Basically MongoDB had defaults that threw data over the wall and didn't send acknowledgement back to the client, then relied on dirty pages flushing to disk in the background. Well it turns out if you don't actually write your data to disk, you get really nice benchmark results. ( Therefore the MongoDB is a webscale phenomenon with the obligatory famous video: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs ) So a lot of people who didn't know how things work were impressed by sending data to /dev/null at high speed and saw postgres as slow and uncool. It was of course debunked since then but the vibe kind of hung around.
- jfb 11y ago
  It's older than that. Postgres used to be compared directly with MySQL, back when ISAM was MySQL's "storage" engine. It was definitely slower -- of course it was doing more -- but it's really never been slow. But memes are difficult to kill.
gdulli 11y ago
Going back to the late 90s, early 00s there was this idea that MySQL is fast and Postgres is slow. It's not accurate or even relevant anymore because MyISAM is how MySQL got a reputation for being fast, but that's no longer the default table type and people know by now that it's not a good default practice. And Postgres has improved significantly. And proper index use isn't an arcane art anymore. It's been many years since this has been accurate and also many years since this was as widely believed as the author of this article believes. Also, while speed no longer differentiates these databases, it should rarely if ever have been the primary factor in choosing one. (Or in avoiding Postgres in general.)
chubot 11y ago
It's because SQL has no performance model. You can't tell by looking at the code (the query) what the performance will be like. For example, you can speed up or slow down code by orders of magnitude by changing a line in a completely different part of the code base (i.e. adding a index). And it's also not an orthogonal change -- increasing your read speed decreases your write speed. The common case for business apps is suboptimal schemas and missing indices. Postgres is fast enough, but it's not trivial to use well. On the other hand, anyone who has programmed in Python or Ruby pretty much has an intuitive feel for how well Redis operations perform. With SQL you get these wild swings, depending on what the query optimizer does. I'm not saying you should use Redis -- it's worth it to learn how to use Postgres. But there's just a lower barrier to entry for non-SQL solutions.
- acdha 11y ago
  > On the other hand, anyone who has programmed in Python or Ruby pretty much has an intuitive feel for how well Redis operations perform. … have you ever seen that not inevitably lead to wild performance swings as people reinvent SQL in their favorite abstraction layer? The same kind of developers who used to make an ORM demand-load a million objects to calculate a number are now doing that with Redis, Mongo, DynamoDB, etc. and telling themselves that it's okay for it to take 5 minutes to sum a million records because it's Big Data™️. I would posit that you're more likely to see good performance from a database engine with many thousands of engineer-hours poured into optimizations than what the average developer is going to produce reinventing a reporting language in Ruby/Python. Those same developers who can't add an index on a SQL database are not suddenly going to figure out how to maintain denormalized records in Redis.
  - crdoconnor 11y ago
    >telling themselves that it's okay for it to take 5 minutes to sum a million records because it's Big Data If it's the kind of query you run every week, it probably is okay. I've not optimized tons of queries like that before - and prevented other developers from doing so - not because it's "big data", but simply because the risk introduced by changing the code and the effort involved in mitigating that risk simply didn't make the optimization worthwhile. In most cases I never would have built it myself from the ground up in such a way that it would take 5 minutes (e.g. without indexes), but somebody else's dumb system that's running in production and solving real human problems in an entirely acceptable time frame is still code that's solving people's problems. And, changes always come with a higher cost and risk than most developers imagine - especially in big systems.

by bigdubs 11y ago

ubercore 11y ago

I think the impression lingers from the early days when MySQL with myisam was the scaling "secret sauce" for everyone, because it leaves behind so many features. I don't know that MySQL was ever significantly faster after InnoDB became the engine most people used.

davidw 11y ago
Mysql was fast in the same way that a bicycle going down a hill without brakes is 'fast'.
- meritt 11y ago
  You understand this is the sort of ignorant rhetoric that leads to the OP's post, right? InnoDB has been available for years and has been the default storage engine for nearly 6 years. Maria and Percona both default to XtraDB. The vast majority of MySQL criticisms haven't been valid for nearly a decade.
  - davidw 11y ago
    You understand "was", don't you? Mysql really took hold around 2000. Postgres was a perfectly valid option back then, too, but... "fast!". InnoDB still doesn't do DDL transactions, does it? That said, clearly Mysql has gotten more robust and Postgres faster.

rdtsc 11y ago

> I'm not sure where this mantra that pgsql is slow comes from. MongoDB factor is probably why from a few years back. Basically MongoDB had defaults that threw data over the wall and didn't send acknowledgement back to the client, then relied on dirty pages flushing to disk in the background. Well it turns out if you don't actually write your data to disk, you get really nice benchmark results. ( Therefore the MongoDB is a webscale phenomenon with the obligatory famous video: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs ) So a lot of people who didn't know how things work were impressed by sending data to /dev/null at high speed and saw postgres as slow and uncool. It was of course debunked since then but the vibe kind of hung around.

jfb 11y ago
It's older than that. Postgres used to be compared directly with MySQL, back when ISAM was MySQL's "storage" engine. It was definitely slower -- of course it was doing more -- but it's really never been slow. But memes are difficult to kill.

gdulli 11y ago

Going back to the late 90s, early 00s there was this idea that MySQL is fast and Postgres is slow. It's not accurate or even relevant anymore because MyISAM is how MySQL got a reputation for being fast, but that's no longer the default table type and people know by now that it's not a good default practice. And Postgres has improved significantly. And proper index use isn't an arcane art anymore. It's been many years since this has been accurate and also many years since this was as widely believed as the author of this article believes. Also, while speed no longer differentiates these databases, it should rarely if ever have been the primary factor in choosing one. (Or in avoiding Postgres in general.)

chubot 11y ago

It's because SQL has no performance model. You can't tell by looking at the code (the query) what the performance will be like. For example, you can speed up or slow down code by orders of magnitude by changing a line in a completely different part of the code base (i.e. adding a index). And it's also not an orthogonal change -- increasing your read speed decreases your write speed. The common case for business apps is suboptimal schemas and missing indices. Postgres is fast enough, but it's not trivial to use well. On the other hand, anyone who has programmed in Python or Ruby pretty much has an intuitive feel for how well Redis operations perform. With SQL you get these wild swings, depending on what the query optimizer does. I'm not saying you should use Redis -- it's worth it to learn how to use Postgres. But there's just a lower barrier to entry for non-SQL solutions.

acdha 11y ago
> On the other hand, anyone who has programmed in Python or Ruby pretty much has an intuitive feel for how well Redis operations perform. … have you ever seen that not inevitably lead to wild performance swings as people reinvent SQL in their favorite abstraction layer? The same kind of developers who used to make an ORM demand-load a million objects to calculate a number are now doing that with Redis, Mongo, DynamoDB, etc. and telling themselves that it's okay for it to take 5 minutes to sum a million records because it's Big Data™️. I would posit that you're more likely to see good performance from a database engine with many thousands of engineer-hours poured into optimizations than what the average developer is going to produce reinventing a reporting language in Ruby/Python. Those same developers who can't add an index on a SQL database are not suddenly going to figure out how to maintain denormalized records in Redis.
- crdoconnor 11y ago
  >telling themselves that it's okay for it to take 5 minutes to sum a million records because it's Big Data If it's the kind of query you run every week, it probably is okay. I've not optimized tons of queries like that before - and prevented other developers from doing so - not because it's "big data", but simply because the risk introduced by changing the code and the effort involved in mitigating that risk simply didn't make the optimization worthwhile. In most cases I never would have built it myself from the ground up in such a way that it would take 5 minutes (e.g. without indexes), but somebody else's dumb system that's running in production and solving real human problems in an entirely acceptable time frame is still code that's solving people's problems. And, changes always come with a higher cost and risk than most developers imagine - especially in big systems.