New in PostgreSQL 10
wiki.postgresql.org
New in PostgreSQL 10
1–10 of 258 posts
Re: New in PostgreSQL 10
#2Full text search in JSON & JSONB looks exciting.
https://wiki.postgresql.org/wiki/New_in_postgres_10#Full_Tex...
Re: New in PostgreSQL 10
#3Floating point timestamps - the only item which affects my work is also one of the few in this wiki page with no description. These were removed with no breaking compatibility.
For anyone else using them, I just did a bit of reading [1] and it looks like they are inferior to default 8 byte timestamps. FP timestamps have microsecond precision around the year 2000, but it drops off as it moves away from there.
I was using them to be the same as some GPS timing code, but it seems this isn't needed or desirable.
[1] https://www.postgresql.org/docs/9.0/static/datatype-datetime...
Re: New in PostgreSQL 10
#4How does PostgreSQL 10 compare with Cassandra for BigData requirements?
Re: New in PostgreSQL 10
#5Full text search in JSON & JSONB looks exciting. https://wiki.postgresql.org/wiki/New_in_postgres_10#Full_Tex...
As someone working with json output from the gmail api I’m curious to see how people smarter than me take advantage of this new functionality so I can adopt it as well.
Re: New in PostgreSQL 10
#6SCRAM authentication looks like a nice security improvement also. No description on the site but http://paquier.xyz/postgresql-2/postgres-10-scram-authentica... gives a good overview.
Re: New in PostgreSQL 10
#7How does PostgreSQL 10 compare with Cassandra for BigData requirements?
Define "big data"? You can buy normal tier 1 server vendor hardware with 6T of memory.
If it fits into 1 machine or a few, it isn't "big data".
Re: New in PostgreSQL 10
#8How does PostgreSQL 10 compare with Cassandra for BigData requirements?
I am interested in the answer to this question, too.
Re: New in PostgreSQL 10
#9Just...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 logic. I wonder what the performance is comparatively between this new "native" partitioning and existing methods (triggers and rules) and whether or not this makes application routing always inferior.
Re: New in PostgreSQL 10
#10How does PostgreSQL 10 compare with Cassandra for BigData requirements?
By no means an expert, but isn’t it Apples and Oranges?
Cassandra is an eventual consistent database.
Postgres is ACID.
My 2c: you don’t need Cassandra or other BigData databases. If you did, you probably wouldn’t ask the question.