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

71–80 of 258 posts

Re: New in PostgreSQL 10

#71

Post by anarazel »

Tostino wrote: post #62
anarazel wrote: post #52

Earlier quoted context omitted.

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?

Not quite sure I understand exactly what you're getting at? Are you wondering if those constraints are less important because you less frequently order by UUIDs? If so, I don't think it makes a huge difference - merge joins are still relevant, and you'll often ORDER BY anyway just to get stable resultsets. If the question is if there's bigger benefits to hash joins for largely unordered data? Then yes, that's true.

Re: New in PostgreSQL 10

#72

Post by gigatexal »

SQLSERVER admin and dev here: these features look really compelling. Though the best part is a team of devs could run these in production and do some self support and basically pay nothing. Not so in SQLSERVER land.

Re: New in PostgreSQL 10

#73

Post by spullara »

gshulegaard wrote: post #30
davedx wrote: post #4

How does PostgreSQL 10 compare with Cassandra for BigData requirements?

Ultimately it depends on your use case and how much tuning/schema design/explicit management you are willing to do. My team lead did a talk at NGINX Conf 2017 which touched on how we tuned Postgres to handle 1 Billion metrics per day for NGINX Amplify ( https://www.nginx.com/products/nginx-amplify/ ). I would link it, but it seems it hasn't been published by our Conf team yet. We did this on 9.4 so the changes outlin…

CitusData yes but RedShift is the Paraccel backend and just uses the frontend of postgresql.

Re: New in PostgreSQL 10

#74

Post by threeseed »

noncoml wrote: post #40
wjossey wrote: post #31

Earlier quoted context omitted.

Having provisioned these sorts of "big data" systems in the past, it's now about how much you have today, it's how much you'll have over a growth period. The advantages of a scale-out system like cassandra, riak (RIP), memsql, big-table, cockroach, etc., are that they can grow with you from 3TB, to 9TB, to 81TB (as an example, if you're on some exponential growth curve with your data). It's not that you can't do it w…

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

> 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 is that a team is established to implement something, it moves into production and then the team either disbands or moves onto something else. Why do you think so many people try and plan for the future ?

In most enterprise companies at least it would be considered a failure to have a project that in a year's time required another business case just to replace the database that the team should've appropriately selected in the first place.

Re: New in PostgreSQL 10

#75

Post by hobolord »

prima-facie wrote: post #65

For anyone using postgres on a daily basis I would highly recommend pgcli. It has a very good auto-complete, and can even suggest JOIN statements (parts of it actually).

do you find that it's significantly slower than just using psql?

Re: New in PostgreSQL 10

#76

Post by wjossey »

simonw wrote: post #61
wjossey wrote: post #49

Earlier quoted context omitted.

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.

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 doing at Citus. It’s great.

Re: New in PostgreSQL 10

#78

Post by SEJeff »

imtringued wrote: post #47
SEJeff wrote: post #7

Earlier quoted context omitted.

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

To be honest 6 TB of data isn't that much. I'd say big data starts at around one petabyte because one petabyte requires 3 servers with 45 [1] 8TB hdds. At this point your data is so large it's impossible to store it on a single physical machine. "big data" usually doesn't require transactions though or at least no transactions across servers so you could probably get away with sharding postgresql via citus. [1] http:…

I agree with this response. Those aren't very big either though. The Dell DSS7000 series servers[1] support 90 x 8TB drives (We run a ceph cluster on 4 of the DSS7500 storage nodes).

[1] http://www.storagereview.com/dell_announces_availability_of_...

Re: New in PostgreSQL 10

#79

Post by pdimitar »

merb wrote: post #29
dalyons wrote: post #16

Earlier quoted context omitted.

Lots of cloud managed dbs are/can be publicly accessible. Eg all heroku hosted Postgres instances

are they? even without ssl? by default?

Not sure about SSL, but in the past customers of mine have copy-pasted full Heroku PG URLs to me and I was able to get in via `psql` immediately.

So yes they're public but their addresses are basically impossible to guess.

Re: New in PostgreSQL 10

#80

Post by bratao »

What I miss the most from Postgree is the compression feature in the same level as RocksDB or Tokudb. The actual compression is very bad compared to them.

Do anyone know if they have something planned in this department ?

Post reply on HN