Live data from Hacker News

New in PostgreSQL 10

wiki.postgresql.org

91–100 of 258 posts

Re: New in PostgreSQL 10

#91

Earlier quoted context omitted.

> you don’t need Cassandra or other BigData database. If you did, you wouldn’t ask the question probably. ...and by the time you do, Postgres improvements will have rendered your Big Data medium-sized anyway :-)

you can comfortably fit 8TB of data on a single box running postgres, more dependent on your hardware :)

That's about 1/250th of our working set size. :)

Of course, that's in a Spark cluster running massively parallel queries and not on a single (however large) node.

Re: New in PostgreSQL 10

#92
post #82

Earlier quoted context omitted.

> Designing for the future is a guaranteed project failure. Based on what ? There is no evidence or logic behind this. If you know that you are producing say 1GB a day of data that you must store then it is sensible and prudent to select a technology that can support your needs a year or two from now. And this idea that you always have resources to make a switch later on is rarely the case. The more common scenario i…

Knowing that you will hit the limit of the database in X years is different. Designing for the future is a horrible choice because where do you stop? Eg. Why are you sure that Cassandra, or whatever you choose, will be good enough for the future? Maybe you will need a Spanner type database or something even more big/consistent/feature-full.

[deleted]

Re: New in PostgreSQL 10

#93
post #76
post #61

Earlier quoted context omitted.

Have you considered Citus as your scale-out solution? https://www.citusdata.com - maybe you can have your PostgreSQL and eat it too.

Citus seems really cool (this is not a critique of the product), but probably not something I’d use. They seem to be very close in feature set to bigquery, and if I have to choose between the two bigquery wins for me. There are definitely situations where citus is a better solution, but I think the scenarios where I could need a scale out analytics platform, I’d choose BQ. Still, very supportive of what they are doin…

MemSQL would be the on-premise alternative to BigQuery, RedShift, Snowflake and the others.

Citus is more focused on scalable OLTP rather than OLAP scenarios, giving you essentially an automatically sharding postgres database. Heap does use it for analytics but that's more so because of the JSON support and indexing in postgres itself.

Re: New in PostgreSQL 10

#94
> ICU Collation Support

This tiny little mention is a massive win! We now have access to the "und-x-icu" collation. As the postgres docs[1] put it: "ICU root collation. Use this to get a reasonable language-agnostic sort order."

I've been waiting on this forever. Columns containing strings from any/all languages can now be sorted well enough to use postgres in truly multi-language applications. If your application has users writing in English, German, Russian, Japanese, et al, using the "und-x-icu" collation should make your application much more user-friendly (as opposed to using the en_US or C locale).

The ICU root collation is far from a perfect system, but it's the best option available today. I've been tied to MySQL purely for its similarly-purposed utf8mb4_unicode_ci collation. Now I can give postgres another very serious look.

[1] https://www.postgresql.org/docs/10/static/collation.html

Re: New in PostgreSQL 10

#95

Earlier quoted context omitted.

agreed. after years of having used Oracle and SQL Server at work, to find I could have a working database in about 10 seconds with sudo apt-get install postgresql was amazing to me!

SQL Server on Linux in a container is just as easy now: docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=password' -p 1433:1433 -d microsoft/mssql-server-linux EDIT: Or with apt-get too: sudo apt-get install -y mssql-server https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-...

That's not as easy in at least two ways: having to use docker and know that command line.

Re: New in PostgreSQL 10

#96
Does anyone have any use cases where PostgreSQL falls down/loses to other DB systems? I know sharding/replication has long been a sticking point, but what else is there?

Why do people still choose MySQL/MariaDB/Oracle over PostgreSQL at all?

Re: New in PostgreSQL 10

#97
post #4

How does PostgreSQL 10 compare with Cassandra for BigData requirements?

They are completely different:

Postgres - Solid single-node relational database with SQL standards support, JSON, fulltext search, custom data types, ACID transactions, foreign data access, and more. HA/scaling through replication and some 3rd party offerings for automatic sharding, failover and multi-master if you need it. Great as the operational source-of-truth for your core data.

Cassandra - Distributed wide-column (basically advanced key/value) meant to run as a cluster of machines with native support for multiple data centers. Limited "SQL" support which is really only used for defining tables. Data access is very different (everything is an upsert or delete) with variable per-query consistency settings. Great if you need data spread globally, 100% availability, eventual consistency fast key/value, and some interesting data access patterns.

If you want high-performance Cassandra, look at ScyllaDB first. If you need something in between Cassandra and Postgres, look at CockroachDB.

Re: New in PostgreSQL 10

#98

Just...wow. * Native partitioning * Parallel query Honestly, some very welcome quality of life improvements for use cases even outside of what I would consider "Big Data". > This means that users no longer need to create triggers for routing data; it's all handled by the system. Trigger routing has always been a performance foot gun...to the point that it's sometimes better to handle table routing in application logi…

I worry that having things "all handled by the system" can be even more of a performance footgun. I mean that users will be able to do things that are allowed by the docs, but which result in, expensive and hard-to-see things are happening under the hood.

This is a valid concern, I've seen simple automatic optimizations backfire before. An example I remember from MS Sql Server (older versions) of a very simple optimization of using indexes can backfire with the dynamic filter pattern:

where ((@foo is null) or (foo = @foo))

and ((@bar is null) or (bar = @bar))

Depending on statistics, order of execution, indexes in place and phase of the moon this could produce fast results or have to revert to a full table scan (because it uses a cached query plan with the wrong index).

Devs still have some awareness of how queries translate to actual running instructions and to measure that the results are in line with what is expected.

Re: New in PostgreSQL 10

#99

Does anyone have any use cases where PostgreSQL falls down/loses to other DB systems? I know sharding/replication has long been a sticking point, but what else is there? Why do people still choose MySQL/MariaDB/Oracle over PostgreSQL at all?

Yes, if you have a need to update large amounts of records. For example, updating a single column of all your records will cause the whole table to be rewrite, thus causing a super high IO load.

Re: New in PostgreSQL 10

#100
post #95

Earlier quoted context omitted.

SQL Server on Linux in a container is just as easy now: docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=password' -p 1433:1433 -d microsoft/mssql-server-linux EDIT: Or with apt-get too: sudo apt-get install -y mssql-server https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-...

That's not as easy in at least two ways: having to use docker and know that command line.

That command line is basic docker usage. Containers are far easier and cleaner than apt/yum installations at this point but you can just do this too:

   sudo apt-get install mssql-server
Post reply on HN