Re: Use of additional index columns in rows filtering

From: Maxim Ivanov <hi+postgresql(at)yamlcoder(dot)me>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use of additional index columns in rows filtering
Date: 2023-02-15 17:15:50
Message-ID: D8rMucmbb9P_obfLcDew74oclmkhdRYRUak_4ATN21F0FD9GsLBDz2iFqWSh3Xj57Il8e4neqyqTCFBmD04oWYssyfPEAsiQtKae7akZa6U=@yamlcoder.me
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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? If tuple is not visible it shouldn't matter, if it is visible then error will be reported by the same routine which does filtering now (ExecQual?).

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-02-15 17:57:41 Re: We shouldn't signal process groups with SIGQUIT
Previous Message Tomas Vondra 2023-02-15 17:01:50 Re: Use of additional index columns in rows filtering