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

Things I hate about PostgreSQL (2020)

rbranson.medium.com

Post reply on HN
Print view View original

31–40 of 255 posts

Re: Things I hate about PostgreSQL (2020)

#31

Post by oblio »

I_am_tiberius wrote: post #26
theshrike79 wrote: post #19

Earlier quoted context omitted.

I think I've heard a saying about this, something about premature optimisation...

Sure you shouldn't care about scaling at the beginning. But why should you start using a system that you already know won't scale in the future?

> Sure you shouldn't care about scaling at the beginning. But why should you start using a system that you already know won't scale in the future?

Because it's well supported and solid otherwise? There's a wealth of documentation, resources of many kinds, software built around it (debugging, tracing, UIs, etc.). Because there's a solid community available that can help you with your problems?

What alternative technology is there that scales better? I guess MySQL could be it, but doesn't MySQL also come with a ton of its own footguns?

Re: Things I hate about PostgreSQL (2020)

#32

Post by oblio »

Maybe there are some core PostgreSQL hackers here:

I know this probably sounds silly but for the transaction ID thing, it does seem like a big deal, is it really insurmountable to make it a 64 bit value? It would probably push this problem up to a level where only very, very few companies would ever hit it and from a (huge) distance the change shouldn't be a huge problem.

Re: Things I hate about PostgreSQL (2020)

#33

Post by lmm »

junippor wrote: post #17
crimper wrote: post #15

Earlier quoted context omitted.

i think you need to provide more details for a good reply. what changed between the time index was used and when it wasn’t? I also had to “convince” postgresql to use my index but that lead to a much better design

> i think you need to provide more details for a good reply. what changed between the time index was used and when it wasn’t? I also had to “convince” postgresql to use my index but that lead to a much better design I disagree: given that nothing changed, I don't think any details need to be provided. The question is NOT "Is postgresql's choice better than mine?" The question is "A certain design was working and sudd…

I guarantee you that something changed. Maybe the row count passed a certain threshold. Maybe you upgraded the database version.

If you don't want the query planner to pull arbitrary execution behaviour out of its ass, why are you using an SQL database in the first place? The whole point of SQL is that you declare your queries and leave it up to the planner to decide, and for that to be at all workable the planner needs to be free to decide arbitrarily based on its own heuristics, which will sometimes be wrong.

Re: Things I hate about PostgreSQL (2020)

#34

Post by I_am_tiberius »

marcus_holmes wrote: post #25
I_am_tiberius wrote: post #18

Earlier quoted context omitted.

The problem is that you want to build something that can scale in the future.

ffs, this attitude causes massively more problems than it solves. 1. You can always change later. Uber switched from Postgres to MySQL when they had already achieved massive scale. 2. You don't know what scaling problems you're going to get until you've scaled. 3. Systems designed to scale properly sacrifice other abilities in order to do that. You're actively hurting your velocity with this attitude. 4. Every single…

ffs, this attitude causes massively more problems than it solves.

I don't think that it causes so many problems to just use MySQL instead of Postgres from the very beginning of a project. I like using Postgres and I understand that I shouldn't care about scaling but if a make a good decision from the very beginning it can't hurt.

Re: Things I hate about PostgreSQL (2020)

#35

Post by why_Mr_Anderson »

junippor wrote: post #9
glogla wrote: post #4

The first paragraph, > Over the last few years, the software development community’s love affair with the popular open-source relational database has reached a bit of a fever pitch. This Hacker News thread covering a piece titled “PostgreSQL is the worlds’ best database”, busting at the seams with fawning sycophants lavishing unconditional praise, is a perfect example of this phenomenon. is exactly the kind of gratui…

Ok, what do you say about this one? > #9: Ridiculous No-Planner-Hints Dogma One of these "query shifts" that the author mentions happened with a production database where I work. It was down for two days. The query planner used to like using index X but at some point decided it didn't want to use that and decided it wanted to do a table scan inside a loop instead. Meaning: one day a certain query was working fine, th…

(I'm not not very familiar with Postgres, but this is common among RDBMSs). What changed is size and/or statistics. Also, if the Query Optimizer supports something like parameter sniffing, that happened. Unacceptable? Not really. Annoying? Very much so.

Re: Things I hate about PostgreSQL (2020)

#36

Post by MaxBarraclough »

vemv wrote: post #12
__jem wrote: post #10

Earlier quoted context omitted.

You have to put your data somewhere... are commercial database vendors or nosql solutions that much better?

I cannot make an expert assessment myself but for one thing mysql is occasionally picked precisely because of its HA story. It was the case in a couple past jobs of mine, back then I didn't particularly appreciate it but now I might see it with different eyes. Also commercial databases do have a better HA story - at least that's their reputation. The current status quo is that everything should be free, but obviously…

What do you make of Amazon Aurora?

Re: Things I hate about PostgreSQL (2020)

#37

Post by oblio »

I_am_tiberius wrote: post #24
o_p wrote: post #22

Earlier quoted context omitted.

Its better to work on getting all those users before planning what color the ferrari will be..

Exactly. That's why it would be good to have a system which is prepared for scaling in the future.

What's that system? MySQL? Are there any other OSS RDBMSes which are comparable and scale better?

Re: Things I hate about PostgreSQL (2020)

#38

Post by pdw »

otikik wrote: post #2

I will add one minor point to this list: The name. To this day I am convinced that the Hazapard UpperCASE usage is what has granted us: - A database called PostgreSQL - A library called libpostgres - An app folder called postgres - An executable called psql - A host of client libraries which chose to call themselves Pg or a variation.

PostgreSQL used to be called Postgres. They renamed it when they added SQL support.

Re: Things I hate about PostgreSQL (2020)

#39

Post by I_am_tiberius »

oblio wrote: post #31
I_am_tiberius wrote: post #26

Earlier quoted context omitted.

Sure you shouldn't care about scaling at the beginning. But why should you start using a system that you already know won't scale in the future?

> Sure you shouldn't care about scaling at the beginning. But why should you start using a system that you already know won't scale in the future? Because it's well supported and solid otherwise? There's a wealth of documentation, resources of many kinds, software built around it (debugging, tracing, UIs, etc.). Because there's a solid community available that can help you with your problems? What alternative technol…

I use Postgres at the moment and I'm happy except for the process per connection part and the upgrade part. Knowing what I know now I think MySQL would have made me happier. On the other hand, it may have caused other issues I don't have with Postgres. I just hope the Postgres team maintains its roadmap based on posts like this.

Re: Things I hate about PostgreSQL (2020)

#40

Post by I_am_tiberius »

oblio wrote: post #37
I_am_tiberius wrote: post #24

Earlier quoted context omitted.

Exactly. That's why it would be good to have a system which is prepared for scaling in the future.

What's that system? MySQL? Are there any other OSS RDBMSes which are comparable and scale better?

I would only have thought of MySQL.
Post reply on HN