<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>da_chicken</author><text>That&amp;#x27;s what I remember, too.&lt;p&gt;That said, Postgres have had a somewhat common problem with poorly selected defaults.&lt;p&gt;I remember that the performance tests back over 10 years ago between Postgres (v7-v9) and MySQL (~v5.0) always showed MySQL way ahead. For a long time people assumed the reason was because MyISAM (the then-default) isn&amp;#x27;t transactional. Except InnoDB was still faster. Okay, but by default MySQL didn&amp;#x27;t `fsync()` after writes. But it was still faster when you enabled that, too.&lt;p&gt;Turns out that Postgres&amp;#x27;s default memory configurations were either largely unchanged from v6 initial releases a decade earlier, or perhaps more accurately they&amp;#x27;re simply set to make the DB not a resource hog out of the box. Well, outside of the development environment, most people set up a dedicated server, and they &lt;i&gt;want&lt;/i&gt; the server to be a resource hog! Most RDBMSs do that automatically. It&amp;#x27;s an odd choice.&lt;p&gt;It&amp;#x27;s been 6-7 years since I used the platform daily, but I would not be surprised if it was still that way. And given the complexity of the memory configuration [0] it&amp;#x27;s hard to NOT make &amp;quot;basic&amp;quot; mistakes.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.postgresql.org&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;runtime-config-resource.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.postgresql.org&amp;#x2F;docs&amp;#x2F;current&amp;#x2F;runtime-config-resou...&lt;/a&gt;</text><parent_chain><item><author>smt88</author><text>I don&amp;#x27;t remember specifics, but that Uber article made it clear that they didn&amp;#x27;t understand how Postgres worked and made some very basic mistakes. The whole thing made them seem surprisingly incompetent, although the general crappiness of Uber apps maybe should have tipped me off sooner.</text></item><item><author>edoceo</author><text>I&amp;#x27;m sure we&amp;#x27;ll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)</text></item></parent_chain></comment><story><title>Index bloat reduced in PostgreSQL v14</title><url>https://www.cybertec-postgresql.com/en/index-bloat-reduced-in-postgresql-v14/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>eloff</author><text>In what way did they make basic mistakes?</text><parent_chain><item><author>smt88</author><text>I don&amp;#x27;t remember specifics, but that Uber article made it clear that they didn&amp;#x27;t understand how Postgres worked and made some very basic mistakes. The whole thing made them seem surprisingly incompetent, although the general crappiness of Uber apps maybe should have tipped me off sooner.</text></item><item><author>edoceo</author><text>I&amp;#x27;m sure we&amp;#x27;ll get a bunch of (well deserved) praise for PG here but, does anyone have a case where PG really shit the bed? (Besides the Uber one) (which is its own long thread)</text></item></parent_chain></comment><story><title>Index bloat reduced in PostgreSQL v14</title><url>https://www.cybertec-postgresql.com/en/index-bloat-reduced-in-postgresql-v14/</url></story>