Re: [planner] Ignore "order by" in subselect if parrent do count(*)

Поиск
Список
Период
Сортировка
От Craig James
Тема Re: [planner] Ignore "order by" in subselect if parrent do count(*)
Дата
Msg-id CAFwQ8rfuNATduYJAm8PJbO+arsvP-uFXEvmi6n-f6Q9A_QaESQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [planner] Ignore "order by" in subselect if parrent do count(*)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [planner] Ignore "order by" in subselect if parrent do count(*)
Список pgsql-performance
On Thu, Mar 1, 2012 at 9:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Marcin Miros*aw<marcin@mejor.pl> wrote:
>>> SELECT count(*)
>>> from (select * from users_profile order by id) u_p;
>
>>> "order by id" can be ignored by planner.
>
>> This has been discussed before.  Certainly not all ORDER BY clauses
>> within query steps can be ignored, so there would need to be code to
>> determine whether it was actually useful, which wouldn't be free,
>> either in terms of planning time or code maintenance.  It wasn't
>> judged to be worth the cost.  If you want to avoid the cost of the
>> sort, don't specify ORDER BY where it doesn't matter.
>
> Considering that ORDER BY in a subquery isn't even legal per spec,

That's surprising ... normally it won't affect the result, but with an
offset or limit it would.  Does the offset or limit change the "not
even legal" part?  Something like:

  select * from foo where foo_id in (select bar_id from bar order by
bar_id offset 10 limit 10);

Craig

> there does not seem to be any tenable argument for supposing that
> a user wrote it there "by accident".  It's much more likely that
> he had some semantic reason for it (say, an order-sensitive function
> in a higher query level) and that we'd break his results by ignoring
> the ORDER BY.  I doubt that very many of the possible reasons for
> needing ordered output are reliably detectable by the planner, either.
>
>                        regards, tom lane
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance

В списке pgsql-performance по дате отправления:

Предыдущее
От: Ants Aasma
Дата:
Сообщение: Re: Bad estimation for "where field not in"
Следующее
От: Alessandro Gagliardi
Дата:
Сообщение: efficient data reduction (and deduping)