115 karma · joined July 5, 2012
https://github.com/citusdata/postgres_vectorization_test
As discussed there it definitely showed promise in improving performance for us.
To clarify her goal isn't to land a job, just to learn a new skill and be able to relate to her coworkers that are doing more coding better.
She's someone that has lots of computer experience but the closest she's gotten to programming before is simple Excel functions (think SUM). I think she'll be much more excited by one where she's working on "real world" stuff so I'm leaving a bit towards Creative Programming for Digital Media & Mobile Apps and hope that it spurs her to learn even more.
I do like the decision to separate AtlasDB from the underlying K/V store.
That said the part about Amazon that infuriates me is when they have the movies available but not for rent and only offer the pay $15 to own option. Also the Netflix discovery/browse is experience is light years better than Amazon's.
ICMS is a different implementation of a columnar store for PostgreSQL. I don't know it extremely well but my understanding is that it uses the PostgreSQL shared memory system to allocate memory for a columnar store. This columnar store is not queried via standard SQL commands but rather using a combination of a custom query language and some user defined functions.
At a high level columnar stores are good for analytical workloads and not great for OLTP workloads. Some reasons for this:
* cstore_fdw currently only supports modifying data via the COPY command. This means that UPDATE and DELETE operations aren't yet possible which limits the utility for OLTP workloads.
* The skiplist indexing system works well for analytical workloads where you are aggregating or retrieving a significant number of rows but wouldn't be great for retrieving single rows.
http://googlecloudplatform.blogspot.com/2014/03/announcing-g...
Guess this is just on the front page because of XKCD about the other Google DNS product?
Cryptographers are certainly not responsible for this superstitious nonsense.
Think about this for a moment: whoever wrote the /dev/random manual page seems to
simultaneously believe that
(1) we can't figure out how to deterministically expand one 256-bit /dev/random
output into an endless stream of unpredictable keys (this is what we need from
urandom), but
(2) we _can_ figure out how to use a single key to safely encrypt many messages
(this is what we need from SSL, PGP, etc.).
For a cryptographer this doesn't even pass the laugh test.
Is the argument here simply that a properly encrypted message should look like randomness? And as a result we should be able to turn something non-random into randomness?If you are replacing an existing system I would recommend narrowing the field of candidates and trying a few options with your existing workload.
I'm having a bit of a hard time following your example but I believe if the authoritative DNS provider simply inherited the TTL of the alias target then the behavior would be as desired. This gets back to donavanm's point that this is more an issue with the way ALIAS records are implemented then a problem with the concept of ALIAS records.
One other issue that the author doesn't touch on is that we now have 3 implementations of ALIAS records that I'm aware of (Route 53, github, and Heroku) and there are differences about how they behave. However we have those 3 providers using the same ALIAS to describe similar but significantly different things. This is clearly confusing and potentially disastrous for users.
The other thing I would add is I got some advice (which I now agree with) from a college professor that business should focus on being really innovative/risky in one dimension, not in all. This seems like a good way constrain the areas your business will really be innovating in.
I think the difference we draw between the two is that an engineer builds things that can be used for many purposes (defense or offense for example) and we as a society generally agree with one of those two uses. When a doctor abuses their knowledge to cause pain they are the ones making a choice we disagree with.
Anyways, yes engineers should think about how their work can (and will) be used but I think it's disingenuous to compare them to patient torturing doctors.
Alternatively you can look at what CDNs are hosting the resources and then just use the existing tools to compare the expected performance of each CDN. Of course this comes with a few caveats:
1/ Performance may be different on a given CDN depending on which "package" the customer has purchased. I know was the case ~1-2 years ago for Akamai.
2/ A CDN may perform well for small objects but not for larger objects, make sure you look at representative benchmarks.
3/ JS CDNs using CDN load balancing services like Cedexis mean more work to find all the CDNs that are being load balanced across (jsDelivr uses Cedexis)
(edit: formatting)