On Wed, Jan 29, 2014 at 4:17 PM, Дмитрий Шалашов wrote:
> Thanks for the tip!
>
> Well, index is now used but...
>
> Limit (cost=264291.67..264291.75 rows=31 width=50)
>-> Sort (cost=264291.67..264292.80 rows=453 width=50)
> Sort Key: added
> -> Bitmap Heap Scan on feed
On Wed, Jan 29, 2014 at 3:38 PM, Дмитрий Шалашов wrote:
> I have a table called 'feed'. It's a big table accessed by many types of
> queries, so I have quite a lot of indices on it.
>
> Those that are relevant looks like this:
>
> "feed_user_id_active_id_added_idx" btree (user_id, active_id, added
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
