Re: psql: Greatly speed up "\d tablename" when not using regexes - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: psql: Greatly speed up "\d tablename" when not using regexes
Date
Msg-id CAGECzQTWy6N8F6R_fOhtKR01E51sZh3dDVT13oRRe6znhuwmEA@mail.gmail.com
Whole thread Raw
In response to Re: psql: Greatly speed up "\d tablename" when not using regexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 10 Apr 2024 at 23:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Is it really necessary for Citus' filter to be a security qual rather
> than a plain ol' filter condition?

No, it's not. I think using security quals simply required the least
amount of code (and it worked just fine if you didn't have lots of
tables). I created a PR for Citus to address this issue[1] by changing
to a normal filter condition. Thanks a lot for pointing me in the
right direction to fix this.

> That is, as long as the derived condition is leakproof, there's no
> reason not to let it go before the security qual.  We're probably
> failing to consider generating derived quals for anything that isn't
> qualified to become an indexqual, and this example shows that that's
> leaving money on the table.

I think even though my immediate is fixed, I think this would be a
good improvement anyway.

[1]: https://github.com/citusdata/citus/pull/7577



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: post-freeze damage control
Next
From: Etsuro Fujita
Date:
Subject: Re: Another WaitEventSet resource leakage in back branches