> On 08 Aug 2014, at 03:43, Evgeniy Shishkin <itparanoia@xxxxxxxxx> wrote: > >>>> select * from users join notifications on users.id=notifications.user_id ORDER BY users.priority desc ,notifications.priority desc limit 10; >> >>> In my understanding, i need to have two indexes >>> on users(priority desc, id) >>> and notifications(user_id, priority desc) >>> then postgresql would choose nested loop and get sorted data from indexes. >>> But it wont. >> >> Indeed. If you think a bit harder, you'll realize that the plan you >> suggest would *not* produce the sort order requested by this query. >> It would (if I'm not confused myself) produce an ordering like >> users.priority desc, id asc, notifications.priority desc >> which would only match what the query asks for if there's just a single >> value of id per users.priority value. >> >> Offhand I think that the planner will not recognize a nestloop as >> producing a sort ordering of this kind even if the query did request the >> right ordering. That could perhaps be improved, but I've not seen many >> if any cases where it would be worth the trouble. > And actually with this kind of query we really want the most wanted notifications, by the user. So we really can rewrite to order by users.priority desc, id asc, notifications.priority desc according to business logic. And we will benefit if this case would be improved. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
