Live data from Hacker News

Postgres 11 – A First Look

craigkerstiens.com

141–150 of 193 posts

Re: Postgres 11 – A First Look

#141
post #37

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!

100% naive question: why is mysql and their similars so popular then? Spanner and AWS Aurora base off of more mysql than postregsql from what I can tell. Why?

from second-source information: in the late 90s, just about every database product in the world, from tiny to massive, was tested as a backend to various web sites. Scaling was still being invented. MySQL was simply the fastest (only by microseconds) to return a set of strings to a php page, and php was a fast development environment. Neither php nor MySQL had the rigor that many in the database world demanded, and that was ok. In fact that helped to make the MySQL/php combination fast.

Once the herds picked MySQL (and php) the economies of scale started, and advantages grew. Meanwhile, the proper and safe competitors were generally disgusted (drama word but not entirely an exaggeration) but who cares about them, maybe even a weird positive to the new breed of web devs who were inventing the future.

Re: Postgres 11 – A First Look

#142

Earlier quoted context omitted.

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

Create a table and have a timestamp for your data? Not sure what you are asking. On hand we have: 15+ years old mature product that is widely supported and it can be used as a time series database Other hand: n+1 young database engine with all of the problems that any young data storage engine has (only exception is FoundationDB because those guys actually understood the challenges of writing a reliable data store) T…

Well InfluxDB actually is a time series database. That's all it does.

The query language is optimised for time based queries. The storage is optimised for time series. It is part of the metrics/monitoring ecosystem so it has integrations with tools like Grafana.

PostgreSQL doesn't have any time series capabilities OOTB. It's just people modelling the concept in a relational fashion. No different to how Excel can be used as a time series database.

And seriously everyone should just get over FoundationDB. There are plenty of people who have invented new databases that got it right e.g. Cassandra, HBase, Redis etc.

Re: Postgres 11 – A First Look

#143
post #59

Earlier quoted context omitted.

> CTRL+D works. You like it. Great use that. You don't think anybody needs an alternative? Or you don't think having an alternative will help at all? Fine. Think what you want. One thing's for (mostly) certain: it doesn't hurt. So there's really nothing to complain about. Not complaining about its presence, as per my comment : "While I think it's great to have both options present,..." Just observing that claims of '…

You don't think it's intuitive for a command line application that is entirely driven by commands, there to be a command to exit it? Instead of a key combination? I'm used to Ctrl+D now, but it sure took me a while to figure it out. Are we not confusing intuitive with standardized?

I can't say if anyone else is confusing intuitive with standardised.

I can repeat (again) that I think it's great both options are there.

Given pretty much all the other 'standard' postgres commands are \[a-z] and sometimes \[a-z][a-z] it sounds like more a complaint about \q

Re: Postgres 11 – A First Look

#144
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…

> The background of what you learned on is key to whats intuitive or natural.

That's pretty much the summary of my post.

> If you install Postgres via Postgres.app ...

I had to go lookup what postgres.app actually is -- evidently it's an easy way for Mac users to install postgres.

I don't have a Mac -- which is also true for most people -- so I can't speak to the average mac user's experience or expectations.

As I have (had to repeatedly) say a few times now, I think it's great that multiple options to end the program are available.

I'd imagine for Mac users the 'most intuitive' thing would be to find some magic symbol on their keyboard and combine it with the letter Q.

Re: Postgres 11 – A First Look

#145

Earlier quoted context omitted.

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).

It's not a fork (according to their promotion), it's an 'extension', but not sure I can explain the difference. Their solution looks interesting but pricing wasn't very visible on their website, what you quote is prohibitive for me (where does it say?). But I at least assumed the 'open source' would be free.

Pricing is available here: https://www.citusdata.com/pricing

And the point still stands that this isn't core PostgreSQL. So you can't use managed services like AWS RDS with this. And you're reliant entirely on the vendor for support.

So from the user perspective it is basically a fork.

Re: Postgres 11 – A First Look

#146

> 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 defa…

This feature has me way more excited than I probably should be. Been splitting up relatively simple schema migrations into multiple steps for years now, and definitely welcoming this change.

Re: Postgres 11 – A First Look

#147

Earlier quoted context omitted.

It really is incredible how we can get something as fundamental as a database for free that is so well made and production ready. Can you imagine if there was no postgres? We'd have to use mysql or oracle or gasp mssql.

If MSSQL wasn't tied to the Microsoft ecosystem, I don't think it would get such a bad rap - When I was a dev on the Microsoft product stack I found MSSQL quite a joy to use - reasonably fast, pretty powerful admin tools (SSMS) and pretty easy to interface with as long as you stayed within the MS ecosystem. I did find myself missing SSMS specifically when I moved to non MS stack development, since Postgres' 'official…

MSSQL runs on Linux now. There's even a docker image. https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-...

Re: Postgres 11 – A First Look

#148

Earlier quoted context omitted.

It's not a fork (according to their promotion), it's an 'extension', but not sure I can explain the difference. Their solution looks interesting but pricing wasn't very visible on their website, what you quote is prohibitive for me (where does it say?). But I at least assumed the 'open source' would be free.

Pricing is available here: https://www.citusdata.com/pricing And the point still stands that this isn't core PostgreSQL. So you can't use managed services like AWS RDS with this. And you're reliant entirely on the vendor for support. So from the user perspective it is basically a fork.

OK thanks for this. The product seems promising even if it is not core PG. I'd have to dive into the deep end and test drive to check if the trade-offs would be worthwhile. The 'open source version' seems free, so I guess I could at some point.

Re: Postgres 11 – A First Look

#149
post #55
post #52

Earlier quoted context omitted.

I’m no expert on this topic and have used both PG and MySQL. My preference is MySQL purely because the syntax is easier, or at least consistent with what I learned at uni in the late ‘90s. I also like MySQL workbench, although I’m sure there is an equivalent for PG I haven’t needed to look for one in recent years. If PG allowed me to use the same syntax as MySQL I’d probably switch, purely because experts and those w…

What syntax do you have in mind? Can you give sone example of what you see as easier in MySQL than Postgres? Genuinely curious, I don't have money in that game

i can say that setting up user accounts and permissions to get up and running is, to me, still easier under mysql, because you connect to mysql as root, and do the rest from inside.

postgresql still seems to have 2 ways, but the majority of tutorials will demonstrate the "become the postgres user and add unix-level accounts". Things like having a unix-level "adduser" program that manages pg stuff is... odd to me, because it's not 'self-contained' in the app. It's more system-level admin stuff I need to do or be aware of.

Whenever I bring this up, I get push back that I'm doing it wrong, and that of course you can just create user accounts from within pg itself via psql, and ... all other sort of attendant feedback. This approach had not seemed to be the norm/default approach, nor the one that was in multiple postgres books I had 10 years ago.

I use pg on some projects, but am no expert in it.

Re: Postgres 11 – A First Look

#150
post #87

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…

> Developers tend not to like triggers or stored procedures IMHO because it's code outside their reach in a language most of them don't know, but that's another story.

You can write PG stored procedures in close to a dozen languages between the builtins (pgSQL, Tcl, Perl and Python) and third-party (Java, Ruby, PHP, R, Scheme, JS, …).

The language itself is not why developers don't like stored procedures, it's because stored procedure are an even worse version of image-based languages (like Smalltalk or Self, except they had much better UI, tooling and interaction model): hard to version, hard to update, hard to test, hard to debug, hard to cache, hard to scale, …, and your wide-spread well-supported ancillary tooling goes away pretty much entirely.

Post reply on HN