| From: | John Fak <johnfak75(at)gmail(dot)com> |
|---|---|
| To: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
| Cc: | lalbin(at)scharp(dot)org, seapug(at)postgresql(dot)org |
| Subject: | Re: Postgres Specific issue |
| Date: | 2024-05-08 17:36:03 |
| Message-ID: | CAFhWtzMUaiOdH_u7hg7Hdm5ROyJv0PcYEQrUhQhsCAwO1D09hA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | seapug |
ha ha - np thx
Well looks like its getting a bit of traction for fix/enhancement here and
backport. So thats good. Our developers are used to us fixing any
performance issues from the backend without code change (hints) in oracle
so they kinda want the same in postgres.
https://github.com/ossc-db/pg_hint_plan/issues/190
On Wed, May 8, 2024 at 7:48 AM Jeremy Schneider <schneider(at)ardentperf(dot)com>
wrote:
> 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
>>
>
>
> --
> http://about.me/jeremy_schneider
>
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Jeremy Schneider | 2024-05-08 14:48:29 | Re: Postgres Specific issue |