Re: Use of additional index columns in rows filtering - Mailing list pgsql-hackers

From Maxim Ivanov
Subject Re: Use of additional index columns in rows filtering
Date
Msg-id D8rMucmbb9P_obfLcDew74oclmkhdRYRUak_4ATN21F0FD9GsLBDz2iFqWSh3Xj57Il8e4neqyqTCFBmD04oWYssyfPEAsiQtKae7akZa6U=@yamlcoder.me
Whole thread Raw
In response to Re: Use of additional index columns in rows filtering  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Use of additional index columns in rows filtering
Next
From: Nathan Bossart
Date:
Subject: Re: We shouldn't signal process groups with SIGQUIT