Re: Postgres Specific issue

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
>
>