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

New in PostgreSQL 10

wiki.postgresql.org

Post reply on HN
Print view View original

61–70 of 258 posts

Re: New in PostgreSQL 10

#61

Post by simonw »

wjossey wrote: post #49
noncoml wrote: post #40

Earlier quoted context omitted.

Designing for the future is a guaranteed project failure. If one is starting a new project, hence contemplating what DB to use, starting with an ACID db is a safe bet in most cases(unless of course they are already starting with a huge amount of data). By the time the outgrow the ACID database they will have a better idea of what exactly they need and more importantly they will have the resources to make the switch.…

I don't think we disagree, but I want to be cautious about saying "whatever we start with is always good enough." I'm co-founder of a company, doing all of the technical work, and I too am using a very vanilla stack: Postgres, Elasticsearch, Redis, Memcache, Rails. However, having worked on massive scale-out projects before, I recognize where my pain points are going to be with my tech choices. [1] I'm storing calend…

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

Re: New in PostgreSQL 10

#62

Post by Tostino »

anarazel wrote: post #52
gfodor wrote: post #46

I noticed hash indexes are now crash proof and replicated -- this seems to make them actually usable in production. In other words, this release effectively "adds" a new index type. That seems like a much bigger deal than is being talked about, is there any reason to believe that new databases shouldn't be using hash indexes for columns that won't be supporting range queries? (In other words, pretty much all keys.) I…

I think it's a neat feature. But note that orderedness isn't just useful for range queries, it also helps to satisfy ORDER BY and to allow for merge joins without a sort steps. There's also no yet support for index-only scans (probably never), no constraints, and no multi-column index support. There's also still some performance kinks to work out with the current hash index performance - large when growing the index…

Do you know how that'd work out for those of us with UUID primary keys rather than integer primary keys?

Re: New in PostgreSQL 10

#63

Post by pjungwir »

TCM wrote: post #6

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

Seems like this might make using passwords compliant with FIPS 140-2. (Not sure, so maybe someone else can share their opinion.) Previously I heard in a few places that people would use LDAP to delegate the auth to something else, e.g. here: https://news.ycombinator.com/item?id=12129906

Re: New in PostgreSQL 10

#64

Post by jackmott »

alceta wrote: post #19

If anyone even remotely involved with the maintenance and development of pg reads this thread - Thank you! - for all your efforts in building and improving a first class product that keeps me amazed at the strides it takes with each major. release.

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!

Re: New in PostgreSQL 10

#66

Post by brlewis »

anarazel wrote: post #52
gfodor wrote: post #46

I noticed hash indexes are now crash proof and replicated -- this seems to make them actually usable in production. In other words, this release effectively "adds" a new index type. That seems like a much bigger deal than is being talked about, is there any reason to believe that new databases shouldn't be using hash indexes for columns that won't be supporting range queries? (In other words, pretty much all keys.) I…

I think it's a neat feature. But note that orderedness isn't just useful for range queries, it also helps to satisfy ORDER BY and to allow for merge joins without a sort steps. There's also no yet support for index-only scans (probably never), no constraints, and no multi-column index support. There's also still some performance kinks to work out with the current hash index performance - large when growing the index…

Stop it! You're giving away all possible answers to one of my favorite interview questions.

Edit: not seriously asking you to stop, but the interview question part is true

Re: New in PostgreSQL 10

#68

Post by threeseed »

noncoml wrote: post #10
davedx wrote: post #4

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

> Cassandra is an eventual consistent database.

No. Cassandra is a database with selectable consistency.

You can set it to be strongly consistent (ALL or QUORUM) with the tradeoff being worse performance.

Post reply on HN