81–90 of 258 posts
Earlier quoted context omitted.
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.
[0] https://en.wikipedia.org/wiki/Security_through_obscurity
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.…
> 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…
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.
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.…
No it's not, say that have 2TB of logs daily, good luck designing that with a regular RDMS without sharding / clustering / re-balancing capabilities.
Citus specifically cite analytics and write throughput as their strengths. I believe them. They do seem to charge for shard rebalancing and some other features.
Greenplum comes with an inbuilt data science toolkit (MADlib) and has a long history of dealing with intensive workloads. I don't know if there is a commercial version with extra features. I don't think so, but I haven't looked closely.
Greenplum also gave birth to HAWQ, which uses the Greenplum distributed/parallel query planner to plan queries over Hadoop.
Disclosure: I work for Pivotal, we do most Greenplum development.
Can the xml table accept any xml document? What if it's a bunch of unrelated elements? Can you get back to xml from the table?
To get XML from a table, functions already existed in previous releases (XMLELEMENT etc.).
Earlier quoted context omitted.
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.
Known as "Security through Obscurity" [0] [0] https://en.wikipedia.org/wiki/Security_through_obscurity
It's still not good practice, since most systems treat addresses with far less care than passwords and often save and/or transmit them unencrypted.
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…
Earlier quoted context omitted.
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.
> 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 :-)
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!
docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=password' -p 1433:1433 -d microsoft/mssql-server-linux
sudo apt-get install -y mssql-server
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!
I took the chance to upgrade our PostgreSQL instance. It took less than an hour. It was a smaller database, but the difference in complexity was still impressive.
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…
I guess it would be helpful for this feature to also include some documentation about if/when to use hash indexes, since up to this point the db has issued a warning basically saying "don't use these." Right now I'd imagine that there will be a lot of confusion around it given the feature's history so people will just not consider it.