Craig Kerstiens

You can use the .psqlrc for this purpose, though I suppose you could also real that in via a file on demand, too. You make entries something like:

\set show_slow_queries
'SELECT
(total_time / 1000 / 60) as total_minutes,
(total_time/calls) as average_time, query
FROM pg_stat_statements
ORDER BY 1 DESC
LIMIT 100;'

(got from https://www.craigkerstiens.com/2013/02/21/more-out-of-psql/)

and then later at the command prompt you access it as; ":show_slow_queries".

I have a few system queries like this in my .psqlrc file, but I don't do much which this feature often truth be told. I have a pretty strong knowledge of the database schema I work with, I do a lot of work on systems I don't regularly control so its not dependably available, and readline history suffices for more immediate needs.

That is definitely an underlying problem. Interviews are too short and too stressful to accurately show how good a candidate is.

I'm not particularly good in interviews because I get nervous and stumble over my words. It is not at all like a real working environment, so I think any conclusions you draw from one are necessarily flawed. I recently read about Heroku's interview process, and I think it's great that they can invest so much in evaluating their candidates. They give each new candidate a project to work on and make a hiring decision after it's been completed. (See http://www.craigkerstiens.com/2011/12/02/how-heroku-works-hiring/). I also think it's unsustainable as their company grows but I would love to be proven wrong.

I would start with the Mode Analytics SQL tutorial. It's fairly robust and gets into advanced topics:
https://community.modeanalytics.com/sql/tutorial/introduction-to-sql/

That will get you pretty far but the advanced SQL topics will require the study of what the underlying database provides and how it works. Every database is different in terms of how it implements advanced features, if at all. For example, MySQL doesn't have window functions. For postgres related topics, the documentation is excellent, postgresguide.com gives a high level overview, or you can follow craig's blog (http://www.craigkerstiens.com/) that provides a gentle introduction to many of these topics as well.

What other examples are there of "single dependency stacks"?

This article is really about the versatility and reliability of postgres.

And I'm all in agreement.

Reminiscent of:

https://www.craigkerstiens.com/2017/04/30/why-postgres-five-years-later/

https://webapp.io/blog/postgres-is-the-answer/

http://rachbelaid.com/postgres-full-text-search-is-good-enough/

http://boringtechnology.club/

As much as HN could lead you astray with the hype of this and that tech, articles like the above are some of the most consistently upvoted on this website.

At work we're in the midst of rolling out a sharded Postgres platform based on http://www.craigkerstiens.com/2012/11/30/sharding-your-database/, with the sharding implemented at the application level. The biggest piece of complexity in that post is around designing the sharding in such a way that you can gracefully add more shards later.

Having read the pg_shard readme, it's not clear to me how it addresses that issue. I'd need to have a really clear idea how to handle scaling my cluster before committing to a sharding solution.

This is a really handy list, but misses a few of my favorites.

The first is \e to open up your default $EDITOR for the query. In the past I've actually setup sublime text to open up my last run query, be able to edit it, close and save and it'll execute. I'd imagine you could do the same with vscode, though I'm currently just configured for vim personally.

The second isn't really psql commands, but that you can setup a psqlrc - https://www.craigkerstiens.com/2013/02/13/how-i-work-with-postgres/