Re: Use of additional index columns in rows filtering

Поиск
Список
Период
Сортировка
От Maxim Ivanov
Тема Re: Use of additional index columns in rows filtering
Дата
Msg-id D8rMucmbb9P_obfLcDew74oclmkhdRYRUak_4ATN21F0FD9GsLBDz2iFqWSh3Xj57Il8e4neqyqTCFBmD04oWYssyfPEAsiQtKae7akZa6U=@yamlcoder.me
обсуждение исходный текст
Ответ на Re: Use of additional index columns in rows filtering  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> This isn't a problem for operators found in operator families, because
> we trust those to not have undesirable side effects like raising
> data-dependent errors. But it'd be an issue if we started to apply
> quals that aren't index quals directly to index rows before doing
> the heap liveness check. (And, of course, once you've fetched the
> heap row there's no point in having a special path for columns
> available from the index.)

Assuming operators are pure and don't have global side effects, is it possible to ignore any error during that check?
Iftuple is not visible it shouldn't matter, if it is visible then error will be reported by the same routine which does
filteringnow (ExecQual?). 


If not, then limiting this optimization to builtin ops is something I can live with :)




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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Use of additional index columns in rows filtering
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: We shouldn't signal process groups with SIGQUIT