Re: mark/restore failures on unsorted merge joins

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: mark/restore failures on unsorted merge joins
Дата
Msg-id 125707.1606161260@sss.pgh.pa.us
обсуждение исходный текст
Ответ на mark/restore failures on unsorted merge joins  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: mark/restore failures on unsorted merge joins
Список pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> The problem is that the planner calls ExecSupportsMarkRestore to find
> out whether a Materialize node is needed, and that function looks no
> further than the Path type of T_Index[Only]Path in order to return true,
> even though in this case it's a GiST index which does not support
> mark/restore.

> (Usually this can't be a problem because the merge join would need
> sorted input, thus the index scan would be a btree; but a merge join
> that doesn't actually have any sort keys could take unsorted input from
> any index type.)

Sounds like the right analysis.

> Going forward, this looks like IndexOptInfo needs another am* boolean
> field, but that's probably not appropriate for the back branches; maybe
> as a workaround, ExecSupportsMarkRestore should just check for btree?

Uh, why would you not just look to see if the ammarkpos/amrestrpos fields
are non-null?

            regards, tom lane



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

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: mark/restore failures on unsorted merge joins
Следующее
От: Anastasia Lubennikova
Дата:
Сообщение: Re: DROP relation IF EXISTS Docs and Tests - Bug Fix