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: | Raw Message | Whole Thread | 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) |