Re: Use of additional index columns in rows filtering

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, Maxim Ivanov <hi(at)yamlcoder(dot)me>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
Subject: Re: Use of additional index columns in rows filtering
Date: 2023-07-24 18:42:21
Message-ID: 1597854.1690224141@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Mon, 2023-07-24 at 13:58 -0400, Tom Lane wrote:
>> Please do not put in any code that assumes that restriction clause
>> order is preserved, or encourages users to think it is.

> Agreed. I didn't mean to add any extra guarantee of preserving clause
> order; just to follow the current way order_qual_clauses() works, which
> has a comment saying:
> "So we just order by security level then estimated per-tuple cost,
> being careful not to change the order when (as is often the case) the
> estimates are identical."
> I assumed that the reason for "being careful" above was to not
> unnecessarily override how the user writes the qual clauses, but
> perhaps there's another reason?

I think the point was just to not make any unnecessary behavioral
changes from the way things were before we added that sorting logic.
But there are other places that will result in clause ordering changes,
plus there's the whole business of possibly-intermixed restriction and
join clauses.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2023-07-24 18:58:15 [PATCH] Check more invariants during syscache initialization
Previous Message Jeff Davis 2023-07-24 18:37:13 Re: Use of additional index columns in rows filtering