Well...it's Europe. As a member of the Euro, Spain has vastly less control over their monetary policy than any truly sovereign state on the face of the planet. Conversely, as a member of the EU, they also have vastly less support from a central government than any province or state would have. They also face an incredibly sclerotic bureaucracy and a non-functional political process, dominated by groups and factions which (to put it mildly) do not have their best interests at heart.
To a first approximation, there is nowhere else on Earth where this debt crisis would be simultaneously so serious and so hard to deal with. You can't treat this like you were dealing with the US, or China, South-East Asia. This is Europe and that means that, barring a miracle, we're all[1] probably screwed.
[1]: Well, anyone who relies on the global economy for income, goods, or services, anyhow. Which would be, uh, all of us on HN, at a minimum...
Without thinking about it to hard my guess is there is some overhead in tracking what is readable and what is not readable at the higher read levels. Read uncommitted means it doesn't have to track anything.
There is also another awesome slide deck (this time with annotations) from another presentation from Bill Odom, regarding key mappings: http://billodom.com/talks/vim-key-mapping.pdf
If hibernation didn't use compression, there was no need for CPU involvement due to DMA. Since there would be no CPU involvement, being multi-core enabled wouldn't be of help.
UTC is enough if we have a single instance of an event. If we have a concept of recurring event ("this event will occur on every Monday 9am"), then it's not enough.
I just wanted to highlight that "time" is a human concept that in informal setting means a lot of things, but when you start to model it formally, it can be more complex than a single timestamp.
That doesn't seem more helpful to me... it's just making the worst case worser.
In a situation which other queries would benefit from the id1, id2 order, and it wouldn't pay off creating another index, using a index seek instead a table scan is way better.
Making the worst case worser is the point. My assumption here was that the issue was catching this type of optimization problem during development, in which case using row values would help. The idea isn't that a table scan is better than an index scan, but that an index scan that isn't very selective will progressively get worse in terms of performance as the table grows, and possibly not be caught during development. Row values are the developer's way of saying "I want this condition to match an index on all columns, or not match at all".
> I would just add to this, don't keep battery at 100% (unplug it when it's done charging)
Absolutely incorrect. What makes you think that keeping a 100% charged battery plugged in bad? The device has its own charging circuitry that stops charging when full.
