From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Correct query for monitor |
Date: | 2025-09-26 23:00:13 |
Message-ID: | CANzqJaCWEZv1VomWQh-rqYcgGobnqqF2cVEabcihBzPuXhBXFA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Sep 26, 2025 at 4:15 PM veem v <veema0000(at)gmail(dot)com> wrote:
> Thank you so much for the quick response. I have a follow up question on
> this as below,
>
> If we want to identify, what exact query inside a procedure is taking a
> longer time:- Using any pg_* views, Is there an easy way to tie the
> query_id of the procedure with the query_ids of the internal sqls(those are
> executed within the procedure) to quickly get the culprit sql?
>
Are there queries inside a cursor loop?
> And say , we got the sql and saw a bad plan and we want to change the plan
> or attach a good plan to that query , is there a possible way to do that in
> postgres?
>
>>
PG does not support hints or "attaching plans to queries".
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2025-09-27 06:37:59 | Re: Correct query for monitor |
Previous Message | Adrian Klaver | 2025-09-26 22:17:02 | Re: How do I upsert depending on a second table? |