Re: Design notes for EquivalenceClasses

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Design notes for EquivalenceClasses
Дата
Msg-id
15246.1169081164@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Design notes for EquivalenceClasses Tom Lane <tgl@sss.pgh.pa.us>
Re: Design notes for EquivalenceClasses Teodor Sigaev <teodor@sigaev.ru>
Re: Design notes for EquivalenceClasses Tom Lane <tgl@sss.pgh.pa.us>
Re: Design notes for EquivalenceClasses Teodor Sigaev <teodor@sigaev.ru>
Re: Design notes for EquivalenceClasses "Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>
Re: Design notes for EquivalenceClasses Tom Lane <tgl@sss.pgh.pa.us>
Re: Design notes for EquivalenceClasses Gavin Sherry <swm@linuxworld.com.au>
Re: Design notes for EquivalenceClasses Tom Lane <tgl@sss.pgh.pa.us>
Re: Design notes for EquivalenceClasses Gavin Sherry <swm@linuxworld.com.au>
Re: Design notes for EquivalenceClasses "Simon Riggs" <simon@2ndquadrant.com>
Gavin Sherry  writes:
> I was thinking about this, but in relation to hash joins. A hash join
> cannot be guaranteed to produce output sorted according to the pathkey of
> the outer relation (as explained in the existing README). I wonder,
> however, if it might be useful for hash join to pass a hint that the
> output is known ordered (i.e., the join was not split into multiple
> batches).

Yeah, I've considered that, but I think it'd have to be the other way
around: the planner tells the executor that it's assuming the output is
sorted, hence do not split into multiple batches.  This has the usual
assortment of problems if the planner has badly misestimated the
rowcount :-(
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Jeff Davis
Дата:
От: Tom Lane
Дата:
FAQ