Queries that load users are perfectly fine, they use primary key to do so. Like you mentioned, I would just limit columns that it selects.
Now indexing a boolean column alone does not make much sense, but my intention was to create a filtered index (where published is true), the second column being published at with descending order meaning what within published articles, all of them will be already sorted in disk.
I have included rest of the columns that are in select clause so that database does not have to do extra lookups from the index to the actual table to get remaining columns.
Having such an index means it 100% satisfies published articles query.
Are indexes on boolean columns that beneficial? I'm all for adding it if they are.
The amount of "that" unfortunately needs to be measured. I don't think a full index would make a difference, but a partial one might (if published = false is significantly less used).
in reality this index might be ignored, I don't think the tags table is that big, PostgreSQL might do a sequential scan if it deems it faster
All in all I still want to bring up the question of performance vs memory. My thought was that the includes(:user) is what is eating up a good deal of memory but is not necessarily killing the query. Its purpose here is to eager load user associations but in doing so without selecting columns, it loads the whole objects into memory, which can be costly.
Have you tried the performance vs memory difference by forcing eager loading in the includes?
Queries that load users are perfectly fine, they use primary key to do so. Like you mentioned, I would just limit columns that it selects.
Now indexing a boolean column alone does not make much sense, but my intention was to create a filtered index (where published is true), the second column being published at with descending order meaning what within published articles, all of them will be already sorted in disk.
I have included rest of the columns that are in select clause so that database does not have to do extra lookups from the index to the actual table to get remaining columns.
Having such an index means it 100% satisfies published articles query.
The amount of "that" unfortunately needs to be measured. I don't think a full index would make a difference, but a partial one might (if
published
= false is significantly less used).Something like:
I'm trying to generate a massive
articles
table to see if I can have PostgreSQL activate the index.There is one, but it's on "name", not on lower(name):
with something like this:
in reality this index might be ignored, I don't think the tags table is that big, PostgreSQL might do a sequential scan if it deems it faster
Have you tried the performance vs memory difference by forcing eager loading in the
includes
?With: