Re: Planner issue on sorting joining of two tables with limit

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Planner issue on sorting joining of two tables with limit
Дата
Msg-id AANLkTim_lnLPp_TX4_FHlSzs00K7jQUmsjeYTp8ZPpkR@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Planner issue on sorting joining of two tables with limit  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Fri, May 7, 2010 at 11:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Alexander Korotkov <aekorotkov@gmail.com> wrote:
>>>> I just don't find why it is coincidence. I think that such plan
>>>> will always produce result ordered by two columns, because such
>>>> nested index scan always produce this result.
>
>> Assuming a nested index scan, or any particular plan, is unwise.
>
> I think he's proposing that the planner should recognize that a plan
> of this type produces a result sorted by the additional index columns.
> I'm not convinced either that the sortedness property really holds,
> or that it would be worth the extra planning effort to check for;
> but it's not a fundamentally misguided proposal.

I took a slightly different point - a nested loop will be ordered by
the ordering of the outer side and then, within that, the ordering of
the inner side, presuming (not quite sure how to phrase this) that the
outer side is "unique enough" with respect to the ordering.  I'm not
too sure whether there's anything useful we can do with this
information in a reasonable number of CPU cycles, but it is something
I've noticed before while reading the code.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

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

Предыдущее
От: "joao.pinheiro"
Дата:
Сообщение: Re: Benchmark with FreeBSD 8.0 and pgbench
Следующее
От: Jayadevan M
Дата:
Сообщение: pg_dump and pg_restore