Re: Postgres Specific issue

Hey John - I just saw this blog post from about a month ago which gets into
this topic a bit. Might be worth taking a look to see if it helps.

https://stborden.wordpress.com/2023/04/06/using-the-hint_plan-table-provided-by-the-postgresql-extension-pg_hint_plan/

-Jeremy

On Sun, Apr 28, 2024 at 11:35 AM John Fak <johnfak75(at)gmail(dot)com> wrote:

> Pretty much. Basically the "normalized" form of the SQL is what is meant
> to go into the hit_table. But if you dont get it 100% correct for ovious
> reasons it wont ever find/match on the hash of the text.
> Problem is - somethin like a whitespace or colon or other ? breaks it
> ....... and trying to debug it on code thats 2 pages long is hard.
> SO ideally ....... best way would be to see what the optimizer is
> actually searching for so we can reverse engineer it. So when I do tracing
> ... is see this ...... as $1 - how would I get the actual value of $1 as
> its a recursive engine driven query.
>
> [image: image.png]
>
>
>
> On Sun, Apr 28, 2024 at 9:00 AM Jeremy Schneider <schneider(at)ardentperf(dot)com>
> wrote:
>
>> Do I understand correctly that the core problem is trying to override the
>> plan for a specific SQL, wanting to use the hint table so that the SQL text
>> itself doesn't need to be changed, but the values that have been tried in
>> the hint table haven't changed the plan yet for the SQL which is executed
>> later?
>>
>> Do you have a simplified set of steps that someone else could run, which
>> demonstrate the problem? Like some statements to create a dummy table and
>> then create a hint table entry which "should" work and then running a query
>> that is not impacted by the hint?
>>
>> -Jeremy
>>
>>

--
http://about.me/jeremy_schneider