| From: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
|---|---|
| To: | John Fak <johnfak75(at)gmail(dot)com> |
| Cc: | lalbin(at)scharp(dot)org, seapug(at)postgresql(dot)org |
| Subject: | Re: Postgres Specific issue |
| Date: | 2024-05-08 14:48:29 |
| Message-ID: | CA+fnDAb1nGzC34Fm0pnD7c=B1PvWqdsZtdmNQkZv0VqrdVU2Cg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | seapug |
nevermind, I see that you are the first comment on the blog so obviously
you already saw it 😂
-Jeremy
On Wed, May 8, 2024 at 7:47 AM Jeremy Schneider <schneider(at)ardentperf(dot)com>
wrote:
> 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
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Fak | 2024-05-08 17:36:03 | Re: Postgres Specific issue |
| Previous Message | Jeremy Schneider | 2024-05-08 14:47:33 | Re: Postgres Specific issue |