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

Postgres 11 – A First Look

craigkerstiens.com

Post reply on HN
Print view View original

111–120 of 193 posts

Re: Postgres 11 – A First Look

#111

Post by yawboakye »

craigkerstiens wrote: post #22
jorams wrote: post #3

> Now you can quit Postgres by simply typing quit or exit. Previously you had to use Ctrl + D or \q While this is good to help out beginners a bit, people should really learn Ctrl + D. It works practically everywhere and saves tons of time guessing/remembering and even typing the correct incantation for the program you want to exit.

Original author here. Yes, it's great to learn Ctrl + D. But losing out on beginners that aren't familiar in favor of things that are naturally intuitive is a great way to make those who are new to programming and especially databases feel like they're dumb or not capable of it. I still recall the first time I was in vi and I couldn't figure out how to get out of the damn thing, and don't get me started on arrow keys…

> But losing out on beginners that aren't familiar in favor of things that are naturally intuitive is a great way to make those who are new to programming and especially databases feel like they're dumb or not capable of it.

I disagree with you here, Craig. In my experience I reach for Ctrl + D, Ctrl + C in quick succession to see what succeeds. I've learnt those and it works for most programs that don't trap exits (again, why would you trap exit?). It has saved me from learning how to exit interactive terminals for python, ruby, node, PostgreSQL (psql) without learning their specific instruction. I like that and I'd prefer to have one way of exiting programs that works on all programs on the system than learn what's any programs preferred command.

Re: Postgres 11 – A First Look

#112

Post by nathan_f77 »

> Fear column addition no more

This section was really surprising to read! I use the strong_migrations [1] gem to catch "NOT NULL column with a default value", because it's such a common mistake.

I guess I had assumed that this was just something we had to accept, based on decades of architecture decisions, and the way that Postgres was written. It never occurred to me that it was actually possible to change the default behavior of Postgres and fix the underlying issue.

[1] https://github.com/ankane/strong_migrations#adding-a-column-...

Re: Postgres 11 – A First Look

#113

Post by Avamander »

gaius wrote: post #88
deytempo wrote: post #45

What are some reasons I might consider Postgres over MySQL when choosing a DB platform?

With Postgres you don't need MongoDB, InfluxDB, or any other trendy thing, Postgres does it all, and better than all the wannabes.

Could you please elaborate how to use Postgres as a time series database (like InfluxDB)?

Re: Postgres 11 – A First Look

#114

Post by blattimwind »

pmontra wrote: post #87
jpalomaki wrote: post #81

Earlier quoted context omitted.

Postgres has much better SQL support and has features which will make you smile if you end writing complex queries for some purposes (like reporting).

Yesterday a friend developer told me he was trying to code a query on MySQL to get the latest message of every conversation stored in a table like conversation id, timestamp, user id, message. I did that years ago so I told him he'll find a lot of solutions on Stackoverflow, ugly ones with MySQL and much better ones for PostgreSQL which has a nrow() function. A MySQL DBA solved that problem in that project I worked o…

> He used triggers to store the id of the most recent message of every conversation in another table. That is probably the most efficient solution in any database.

Depends on how often that last message query is run. If it's infrequent, the trigger is just write amplification.

Re: Postgres 11 – A First Look

#115

Post by tormeh »

davidw wrote: post #35
craigkerstiens wrote: post #22

Earlier quoted context omitted.

Original author here. Yes, it's great to learn Ctrl + D. But losing out on beginners that aren't familiar in favor of things that are naturally intuitive is a great way to make those who are new to programming and especially databases feel like they're dumb or not capable of it. I still recall the first time I was in vi and I couldn't figure out how to get out of the damn thing, and don't get me started on arrow keys…

I'm reminded of this bit, from https://www.gnu.org/fun/jokes/ed-msg.html Let's look at a typical novice's session with the mighty ed: golem$ ed ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ? --- Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.

I think I did something like this with vim when I first encountered it. Now I like the damn thing (but still prefer VS Code).

Re: Postgres 11 – A First Look

#116

Post by threeseed »

gaius wrote: post #88
deytempo wrote: post #45

What are some reasons I might consider Postgres over MySQL when choosing a DB platform?

With Postgres you don't need MongoDB, InfluxDB, or any other trendy thing, Postgres does it all, and better than all the wannabes.

This is simply untrue.

MongoDB is a much better JSON store. It's ridiculously faster, has much richer update semantics and it's simply not comparable when it comes to the ease of clustering.

As for time series unless I am confused but PostgreSQL doesn't have any OOTB capabilities.

Re: Postgres 11 – A First Look

#117

Post by tormeh »

craigkerstiens wrote: post #38
Jedd wrote: post #34

Earlier quoted context omitted.

You use the word intuitive a couple of times, and suggest there's a natural way to exit interactive cli programs (and it's not ctrl-d). Yet for me, ctrl-d is my usual first way of trying to exit any shell or cli utility. Whether it's natural or not, I couldn't say. Arguably the nipple is the first and only intuitive interface, everything after that is learned. After many years on my/maria I find the backslash shortcu…

The background of what you learned on is key to whats intuitive or natural. If you came up on an unix based system then yes you'd expect this. If you learned databases via MySQL then you'd expect show database to work. Today though many more are coming to development without an academic or linux background. If you install Postgres via Postgres.app there is a chance you're not at all familiar with a commandline. What…

Most CLIs can be exited with "quit" or "exit". Many trap Ctrl-C, so those two are the first things I try. Didn't know about Ctrl-D before now, and I've worked as a sysadm.

Re: Postgres 11 – A First Look

#118

Post by threeseed »

gaius wrote: post #105
sz4kerto wrote: post #98

Earlier quoted context omitted.

Is that really true? Postgres is great, but it doesn't cater for _all_ use cases. For example, horizontal scalability is -- understandably for an ACID RDBMS -- not as trivial as it is for some document stores.

Check out what Citus are doing with PG https://www.citusdata.com

That's a fork of PostgreSQL.

So it doesn't help you when it comes to using cloud hosted services e.g. AWS or Azure. It's also a commercial product that isn't exactly cheap ($890/node).

Re: Postgres 11 – A First Look

#119

Post by jacques_chester »

alecco wrote: post #108
kstrauser wrote: post #31

A million things like this are why PostgreSQL is the only relational database I consider for, well, pretty much anything. Their approach of “build it safe and then make it fast” has been paying off in spades for a couple of decades now. Thanks for everything you do, psql maintainers!

> “build it safe and then make it fast” I have a lot of respect for the PostgreSQL team. But I think they don't care about the second part, or the constraints of the first part make it impossible. A simple example, the performance of a simple un-indexed DISTINCT on a single string column on a single table, is still quite bad for millions of rows. Also to note, PostgreSQL has too many features for my taste. I get it's…

> A simple example, the performance of a simple un-indexed DISTINCT on a single string column on a single table, is still quite bad for millions of rows.

Why is this surprising?

Re: Postgres 11 – A First Look

#120

Post by scrollaway »

Avamander wrote: post #113
gaius wrote: post #88

Earlier quoted context omitted.

With Postgres you don't need MongoDB, InfluxDB, or any other trendy thing, Postgres does it all, and better than all the wannabes.

Could you please elaborate how to use Postgres as a time series database (like InfluxDB)?

The TimescaleDB plugin is extremely promising: https://www.timescale.com/

Natively without a plugin, it's not possible though.

Post reply on HN