4 ms·
* Check out wal-e (https://github.com/heroku/wal-e https://github.com/heroku/wal-e), we wrote it and we manage 250k postgres databases with it. :) * libpq does
by pvh 14y ago
* Check out wal-e (https://github.com/heroku/wal-e https://github.com/heroku/wal-e), we wrote it and we manage 250k postgres databases with it. :)
* libpq does basically suck, but go has a pretty great native implementation. suggestions are welcome for improvement, patches are even better.
* pg_cancel_backend() plus select-fu on the `pg_locks` table joined with `pg_stat_activity` = joy
* fast count(*) is possible via index-only scans in 9.2
- fdr 14y ago> fast count() is possible via index-only scans in 9.2 I'd like to expand on this. It will be faster, but still involves an O(n) over the qualifying data, but it'll be a lot less data, particularly for tables with wider rows. To some extent this problem is fundamentally unable to reach a small O(1) without introducing more lock contention and expense that many people don't want to pay continuously and across every possible query or dimension that can exist (in the latter case, it is clearly impossible given the existence of arbitrary WHERE clauses), but I think it'd be nice if people could add a new physical construct whereby count(*) queries on certain dimensions can be made faster at the cost of lock contention or resource consumption, not entirely unlike indexes.