Re: sequential scan on select distinct
От | Tom Lane |
---|---|
Тема | Re: sequential scan on select distinct |
Дата | |
Msg-id | 29074.1097163334@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: sequential scan on select distinct (Pierre-Frédéric Caillaud<lists@boutiquenumerique.com>) |
Список | pgsql-performance |
=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?= <lists@boutiquenumerique.com> writes: > Present state is that DISTINCT and UNION are slow with or without using > the GROUP BY trick. Including the index skip scan in the planning options > would only happen when appropriate cases are detected. This detection > would be very fast. You have no basis whatever for making that last assertion; and since it's the critical point, I don't intend to let you slide by without backing it up. I think that looking for relevant indexes would be nontrivial; the more so in cases like you've been armwaving about just above, where you have to find a relevant index for each of several subqueries. The fact that the optimization wins a lot when it wins is agreed, but the time spent trying to apply it when it doesn't work is a cost that has to be set against that. I don't accept your premise that every query for which skip-index isn't relevant is so slow that planning time does not matter. regards, tom lane
В списке pgsql-performance по дате отправления: