From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Cole <davejohncole(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Capturing EXPLAIN ANALYZE for a query without discarding the normal result set |
Date: | 2014-01-15 07:36:08 |
Message-ID: | 52D63A68.6000702@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/13/14, 9:14 PM, Tom Lane wrote:
> Dave Cole <davejohncole(at)gmail(dot)com> writes:
>> It would be really cool if you could direct the EXPLAIN ANALYZE output to a
>> temporary table so that the query being analyzed could execute normally.
>
> What happens if the current transaction rolls back?
>
> If you want noninvasive explain data, contrib/auto_explain offers
> a solution right now. The info goes to the postmaster log, which is
> perhaps less convenient than a temp table for interactive use, but
> it doesn't have the rollback problem --- and you can capture data
> about queries issued by a live application, without hacking the app.
The downside is that you then have to trawl through logs, which may not be easy (or in some hosting environments, possible).
We're actually starting to do the opposite for a lot of automated stuff: we EXPLAIN ANALYZE a CTAS and then read the temp table back out. But that's a lot more data copying than saving the EXPLAIN would be (well, at least normally ;).
As for rollback, dblink or FDW fixes that. Or if you're using a front-end that's sophisticated enough, you can pull it out yourself and do whatever with it.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-01-15 08:08:15 | Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format |
Previous Message | Jim Nasby | 2014-01-15 07:19:57 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |