| From: | Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pghackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Improve ability to display optimizer analysis using OPTIMIZER_DEBUG |
| Date: | 2023-01-03 06:59:00 |
| Message-ID: | 35a06490-6078-bb91-a87f-2f9b259845e1@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 03/01/23 08:38, David Rowley wrote:
> I'm with Tom on this. I've never once used this feature to try to
> figure out why a certain plan was chosen or not chosen.
>
> I'd really rather not see us compiling all that debug code in by
> default unless it's actually going to be useful to a meaningful number
> of people.
>
Okay this makes sense.
>
> Do you actually have a need for this or are you just trying to tick
> off some TODO items?
>
I would say Iatter but reason I picked it up was more on side of
learning optimizer better. Currently, I am left with
explain analyze which does its job but for understanding internal
working of optimizer, there are not much alternatives.
Again, if I know where to put breakpoint, I could see required
path/states but point of this todo item is
ability to do this without need of developer tools.
Also from the thread,
https://www.postgresql.org/message-id/20120821.121611.501104647612634419.t-ishii@sraoss.co.jp
> +1. It would also be popular with our academic users.
>
There could be potential for this as well.
--
Regards,
Ankit Kumar Pandey
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2023-01-03 07:01:10 | Re: Time delayed LR (WAS Re: logical replication restrictions) |
| Previous Message | Alexander Korotkov | 2023-01-03 06:29:00 | Re: Allow placeholders in ALTER ROLE w/o superuser |