| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> |
| Cc: | "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] Explain plan output |
| Date: | 1999-12-27 15:51:05 |
| Message-ID: | 26149.946309865@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Ansley, Michael" <Michael(dot)Ansley(at)intec(dot)co(dot)za> writes:
> Anyway, the point of this mail is to say that I have altered the explain
> code slightly, so that it dumps the results of the explain into a
> table.
What do you mean by that, exactly? You can't expect to fit long explain
outputs into a single table row, so I suppose it's one row per line.
How are the rows identified? What's the expected declaration of the
table?
> I find that a lot more convenient
It strikes me as a lot less convenient for the sorts of things I use
explain for. But I wouldn't object if it were an optional feature:
EXPLAIN [ VERBOSE ] [ INTO <table> ] <query>
which would also solve your problem of figuring out which table to write
to.
> e) The plan id is output using elog. How would I ensure that this gets back
> to any arbitrary client. If I understand right, elogs don't go to ODBC, and
> possibly other, clients.
What's a "plan id", and is it actually necessary?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-12-27 16:09:26 | Re: [HACKERS] memory dilemma |
| Previous Message | Bruce Momjian | 1999-12-27 15:44:59 | Re: [PATCHES] Unlimited query length - The final chapter (part II) |