jugnooken writes:
> Unfortunately, pg still thinks using
> index_social_feed_feed_items_on_social_feed_id is faster although they are
> about the same size :(. Any idea?
On further reflection, the cost estimate that is weird for this number of
rows is not the large one for your preferred index, b
Thank you so much for the prompt reply, Tom. The index is actually fairly new
- but to be safe I issued REINDEX TABLE so that they are all clean. Here are
the sizes of each index right after REINDEX.
db=> select
pg_size_pretty(pg_relation_size('index_social_feed_feed_items_on_social_feed_id_and_po
jugnooken writes:
> Here's the query:
> db=> EXPLAIN ANALYSE SELECT social_feed_feed_items.social_message_id FROM
> social_feed_feed_items WHERE social_feed_feed_items.social_feed_id = 480
> ORDER BY posted_at DESC NULLS LAST LIMIT 1200;
Hello everyone,
I've a query that runs on a table with a matching index to its WHERE and
ORDER clause. However the planner never uses that index. Is there any reason
why it doesn't?
Here's the table:
db=> \d social_feed_feed_items;
Table
"public.social_fe
