Re: BUG #14302: SQL with LIMIT degrades performance seriously
| От | Francisco Olarte |
|---|---|
| Тема | Re: BUG #14302: SQL with LIMIT degrades performance seriously |
| Дата | |
| Msg-id | CA+bJJbx3o_tPQpzbkYqzgMhi0jL53OF0YfpB6iszNOpfd8FhAA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #14302: SQL with LIMIT degrades performance seriously (Kaijiang Chen <chenkaijiang@gmail.com>) |
| Список | pgsql-bugs |
Top posting makes the flow difficult to follow, editing a little bit. >> Why not just create the correct index on each partition? >> (parent_id,user_id) On Wed, Aug 31, 2016 at 2:42 PM, Kaijiang Chen <chenkaijiang@gmail.com> wrote: > It couldn't solve the problem. > I've already created 2 btree indexes, one for parent_id, the other for > user_id. A (parent_id, user_id) index can be used instead of the one for parent_id, so it will nbot need to much extra, and can solve some queries. The planner can normally detected where some keys can be solved directly with a composite index. > Do you mean to create an multi-column index on (parent_id, user_id)? -- > still couldn't solve the problem, since we still need index for user_id (for > other sql) and planner will turn to user_id index. How do you know it will turn to the bad index? Francisco Olarte.
В списке pgsql-bugs по дате отправления: