| From: | "Dian Fay" <di(at)nmfay(dot)com> |
|---|---|
| To: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
| Cc: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>, "Jakub Wartak" <jakub(dot)wartak(at)enterprisedb(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_plan_advice |
| Date: | 2025-11-30 03:16:44 |
| Message-ID: | DELPC4B56Y5A.3OBZ3WCH3T4VX@nmfay.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon Nov 24, 2025 at 11:14 AM EST, Robert Haas wrote:
> On Sat, Nov 22, 2025 at 7:43 PM Dian Fay <di(at)nmfay(dot)com> wrote:
>> Since the policies don't contain any execution boundaries, all the quals
>> should be going into a single bucket for planning if I understand the
>> process correctly. The bitmap heap scan should be a candidate given the
>> `tags &&` predicate (and indeed if I switch to a privileged role, the
>> advice matches successfully without any policies in the mix), but gdb
>> shows the walker bouncing out of pgpa_walker_contains_scan without any
>> candidate scans for the BITMAP_HEAP_SCAN strategy.
>
> In this particular case, I think the problem is that the user-supplied
> qual item.tags @> ARRAY[id] is not leakproof and therefore must be
> tested after the security qual. There's no way to use a Bitmap Heap
> Scan without reversing the order of those tests.
Right, I keep forgetting the functions underneath those array operators
aren't leakproof. Thanks for digging.
> And honestly, this is one of the things I'm worried about if we go
> forward with this, that we'll get a ton of people who think it doesn't
> work because it doesn't force the planner to do things which the
> planner rejects on non-cost considerations. We're going to need really
> good documentation to explain to people that if you use this to try to
> force a plan and you can't, that's not a bug, that's the planner
> telling you that that plan shape is not able to be considered for some
> reason.
Once we're closer to consensus on pg_plan_advice or something like it
landing, I'm interested in helping out on this end of things!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2025-11-30 06:01:42 | Re: proposal: schema variables |
| Previous Message | Thomas Munro | 2025-11-30 02:20:35 | Re: pgsql: Inline pg_ascii_tolower() and pg_ascii_toupper(). |