From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: explain vs auto_explain |
Date: | 2024-10-19 18:01:56 |
Message-ID: | 1128627.1729360916@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Sat, Oct 19, 2024 at 10:43 AM Vijaykumar Jain <
> vijaykumarjain(dot)github(at)gmail(dot)com> wrote:
>> i tried to check the code for auto_explain , there is nothing that helps
>> understand why it was provided as a separate .
> Probably because output to log was easier than reworking the internals to
> make output to client happen.
The reason that auto_explain exists is to capture plans for queries
that are being issued by real applications --- which aren't programmed
to issue EXPLAIN for themselves, and likely don't have a good place to
put the data if they did. Also, auto_explain can capture runtime
details for queries that are really being executed and delivering
results, whereas EXPLAIN ANALYZE doesn't deliver the query results and
thus can't be shoehorned into real applications. So it's partly a
matter of not having a protocol spec that would allow the EXPLAIN data
to be delivered on a side channel, but mostly a recognition that
rewriting applications to capture such data would be painful.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vijaykumar Jain | 2024-10-19 18:18:12 | Re: explain vs auto_explain |
Previous Message | David G. Johnston | 2024-10-19 17:50:01 | Re: explain vs auto_explain |