Re: pg_plan_advice

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!

In response to

Browse pgsql-hackers by date

  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().