Re: [PERFORM] trick the query optimiser to skip some optimisations

2014-01-30 Thread Jeff Janes
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

Re: [PERFORM] trick the query optimiser to skip some optimisations

2014-01-30 Thread Sergey Konoplev
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

Re: [PERFORM] trick the query optimiser to skip some optimisations

2014-01-29 Thread Дмитрий Шалашов
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 (cost=1850.99..264278.18 rows=453 width=50) Recheck Con

Re: [PERFORM] trick the query optimiser to skip some optimisations

2014-01-29 Thread Jeff Janes
On Wed, Jan 29, 2014 at 3:38 PM, Дмитрий Шалашов wrote: > "feed_user_id_added_idx2" btree (user_id, added DESC) WHERE active_id = > user_id AND type = 1 > ... > SELECT * FROM feed WHERE user_id = ? AND type = 1 AND active_id = user_id > ORDER BY added DESC LIMIT 31; > > But it doesn't use th