2,236 karma · joined March 7, 2015
If so, though, hopefully there's a silver lining of faster incorporation of new pgsql features into the Aurora/PG service.
There's a more complete discussion of these here: https://sqlperformance.com/2016/11/sql-server-2016/big-deal-...
Edit: fixed link.
From the perspective of uniformity and availability, while C# provided asynchronicity via callbacks before the introduction of Tasks in the 4.5 release of the .NET Framework, all the core libraries that used callback-style async (as well as some that had been strictly synchronous-only) were updated with Task-based overloads, so there are no problems with Task-based async being inconsistently available. Additionally, adoption of Task-based async in third-party libraries has been high, so it's relatively uncommon to encounter code that does not support it.
From the perspective of code productivity, it's hard to get much better than simply adding the async and await keywords where necessary. As a very simple example, consider a typical server application that receives requests via HTTP, processes them via an HTTP call to another service as well as a database call, and then returns an HTTP response. The sync code (blocking with a thread-per-request model) might look something like this:
void handleRequest(HttpRequest request) {
var serviceResult = makeServiceCallForRequest(request);
var databaseResult = makeDatabaseCallForRequest(request);
sendResponse(constructResponse(request, serviceResult, databaseResult));
}
async Task handleRequestAsync(HttpRequest request) {
var serviceResult = await makeServiceCallForRequestAsync(request);
var databaseResult = await makeDatabaseCallForRequestAsync(request);
await sendResponseAsync(constructResponse(request, serviceResult, databaseResult));
}
async Task handleRequestAsync(HttpRequest request) {
var serviceResultTask = makeServiceCallForRequestAsync(request);
var databaseResultTask = makeDatabaseCallForRequestAsync(request);
await sendResponseAsync(constructResponse(request, await serviceResultTask, await databaseResultTask));
}
This is just a consequence of the PK being a clustered index in InnoDB which has both pros and cons. One of the big cons is that all of the columns of the PK are implicitly added to every secondary index as the row identifier. That isn't a big problem if your PK is a single column int, but if it's multiple columns, that often results in unnecessary bloat in your secondary indexes. Ideally (as in, dare I say, MS SQL Server), you'd have the option of a clustered or non-clustered PK for your table so you could choose the optimal index structure for your workload on a per-table basis.
Some earlier (2013) discussion on the same topic: https://wiki.postgresql.org/wiki/2013UnconfPluggableStorage
SMPY researchers say that even modest interventions—for example, access to challenging material such as college-level Advanced Placement courses—have a demonstrable effect. Among students with high ability, those who were given a richer density of advanced precollegiate educational opportunities in STEM went on to publish more academic papers, earn more patents and pursue higher-level careers than their equally smart peers who didn't have these opportunities.
Despite SMPY's many insights, researchers still have an incomplete picture of giftedness and achievement. “We don't know why, even at the high end, some people will do well and others won't,” says Douglas Detterman, a psychologist who studies cognitive ability at Case Western Reserve University in Cleveland, Ohio. “Intelligence won't account for all the differences between people; motivation, personality factors, how hard you work and other things are important.”