From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql: Greatly speed up "\d tablename" when not using regexes |
Date: | 2024-04-11 10:30:58 |
Message-ID: | CAGECzQTWy6N8F6R_fOhtKR01E51sZh3dDVT13oRRe6znhuwmEA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 10 Apr 2024 at 23:51, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2024-04-11 10:41:04 | Re: Another WaitEventSet resource leakage in back branches |
Previous Message | Tomas Vondra | 2024-04-11 10:26:38 | Re: post-freeze damage control |