Live data from Hacker News

New in PostgreSQL 10

wiki.postgresql.org

51–60 of 258 posts

Re: New in PostgreSQL 10

#52
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 quickly or under very high concurrency.

Re: New in PostgreSQL 10

#53
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.

It's an improvement for sure, but I am curious -- does anyone situate a Postgres instance where it is publicly accessible? Who was asking for this feature?

Several reasons:

- Checkbox item for people not wanting MD5 anymore.

- Storing passwords on the server in a securely hashed way, so the admin won’t know your password.

- PostgreSQL developers getting out of the roll-your-own-crypto game.

Re: New in PostgreSQL 10

#54
post #42

Earlier quoted context omitted.

Maybe. I recently updated some of my company's internal training material, and discovered there still isn't a single (good) definition of "Big Data". Most definitions talk evaluating data on four dimensions: volume, variety, velocity and veracity. That's still a vague, but it's more helpful than looking at volume alone. Besides, if we picked machine size as _the_ definition, it would change every year. And that feels…

I've also struggled with the definition of Big Data. I typically see "size" as being the line of demarcation people throw around when thinking about Big Data, but I think it's it's actually size + latency that's the real definition. If I have a 12TB dataset, and I need to be able to find a single record in that dataset, and return the results to a process in less than one second, I don't believe that needs to be cons…

[deleted]

Re: New in PostgreSQL 10

#55
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.

It's an improvement for sure, but I am curious -- does anyone situate a Postgres instance where it is publicly accessible? Who was asking for this feature?

I think by far the biggest benefit is being able to check the "no insecure crypto algorithms used" box. Even though the way md5 was used wasn't really that concerning security wise, it constantly comes up.

Re: New in PostgreSQL 10

#56
post #49
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…

Agreed

Re: New in PostgreSQL 10

#57

Does anyone know whatever happened to the columnar storage work that 2nd quadrant posted on their blog: https://blog.2ndquadrant.com/postgresql-10-roadmap/ Is this essentially a pipe dream?

Not a priority for 2Q at the moment. Still general interest in the community, but hard to predict right now.

Re: New in PostgreSQL 10

#58
Would love to know about FDW push down. That could be really good for specialized applications where you want to use a relational db and wrap a specialized data store outside postgres with a FDW.

Re: New in PostgreSQL 10

#59
What is the current best option for Postgres failover? I looked at this at the start of the year, and found lots of options, but all of them seemed to have various drawbacks, and none were natively supported or built-in to Postgres.

Re: New in PostgreSQL 10

#60

Does anyone know whatever happened to the columnar storage work that 2nd quadrant posted on their blog: https://blog.2ndquadrant.com/postgresql-10-roadmap/ Is this essentially a pipe dream?

There seems to be an in progress patch for pluggable storage:

https://www.postgresql.org/message-id/CAJrrPGdMu8TzxpRZQKK5E...

The PostgreSQL 11 roadmap also mentions "multi-model" database

https://wiki.postgresql.org/wiki/Fujitsu_roadmap#Multi-model...

Post reply on HN