Re: Use of additional index columns in rows filtering

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: 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:23:32
Message-ID: a0af8d34bb0e814f714af335443f123d5167d136.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Regardless, my point was just to make minimal changes now that are
unlikely to cause regressions. If we come up with better ways of
ordering the clauses later, that could be part of a separate change. (I
think Peter G. is pointing out a complication with that idea, to which
I'll respond separately.)

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-07-24 18:37:13 Re: Use of additional index columns in rows filtering
Previous Message Fabrízio de Royes Mello 2023-07-24 18:07:07 Re: Removing the fixed-size buffer restriction in hba.c