11–20 of 41 posts
Really solid list! I went through all the Active Record, query design, and index design tips for PostgreSQL, and can +1 them all. Nice work. For readers who want all of these and more in book form, with a sample Rails app and big data to test with (generated), please consider my book: High Performance PostgreSQL for Rails https://news.ycombinator.com/item?id=38407585 The book helps readers build database skills with…
Good stuff but the `size`, `count`, `length` section just intensifies my dislike for ORMs. ORMs bury all of the SQL, just for devs to dig it back up when they realize it's important for performance. Now you have to be a SQL expert and an ActiveRecord expert.
This is a place where I think tools like Rubocop help. They can be configured to point out method swaps like this (size over count) automatically which is a relatively low effort task to change the code.
With those rules/linting in place, you aren’t throwing out the benefits of AR (ORM), and hopefully leveraging their useful methods like these that help avoid unnecessary queries.
Ever read those articles that explain half the internet is unavailable because of some random e.g. cloudflare outage? That.
Some good advice here, but the “don’t index boolean columns” needs an “it depends” caveat, since Postgres will sometime use multiple boolean indexes to perform a bitmap index scan, which can be advantageous.
CREATE INDEX index_accounts_balance ON accounts (id) WHERE boolean_flag;
Pretty sure this only applies to HTTP/1 and you'll get better performance with HTTP/2:
"Connection-specific header fields such as Connection and Keep-Alive are prohibited in HTTP/2 and HTTP/3"
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...
"HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection."
> We can’t think of any good reason to do without [CDNn] CDNs are another way to track everybody. So privacy is an excellent reason for not using a CDN.
Really solid list! I went through all the Active Record, query design, and index design tips for PostgreSQL, and can +1 them all. Nice work. For readers who want all of these and more in book form, with a sample Rails app and big data to test with (generated), please consider my book: High Performance PostgreSQL for Rails https://news.ycombinator.com/item?id=38407585 The book helps readers build database skills with…
Good stuff but the `size`, `count`, `length` section just intensifies my dislike for ORMs. ORMs bury all of the SQL, just for devs to dig it back up when they realize it's important for performance. Now you have to be a SQL expert and an ActiveRecord expert.
Really solid list! I went through all the Active Record, query design, and index design tips for PostgreSQL, and can +1 them all. Nice work. For readers who want all of these and more in book form, with a sample Rails app and big data to test with (generated), please consider my book: High Performance PostgreSQL for Rails https://news.ycombinator.com/item?id=38407585 The book helps readers build database skills with…
Awesome, thanks for plugging this here! Exactly the kind of material I was looking for :)