Re: Understanding EXPLAIN ANALYZE output

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: David Fetter <david(at)fetter(dot)org>, "Ed L(dot)" <pgsql(at)bluepolka(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Understanding EXPLAIN ANALYZE output
Date: 2005-02-11 01:11:42
Message-ID: 5014.1108084302@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Michael Fuhr <mike(at)fuhr(dot)org> writes:
> Do PL/Perl and the other PLs require any changes to make this work?
> I tried $rv = spi_exec_query("EXPLAIN $query") but $rv contained
> only the following:

> $rv->{processed} = 0
> $rv->{status} = SPI_OK_UTILITY

Looking around, it seems that the PLs (and a lot of contrib modules) are
using SPI_execute rather than the SPI cursor features --- which is what
I fixed. It looks from the code like SPI_execute does the right things
in terms of returning a tuple table, but it returns completion code
SPI_OK_UTILITY; and these callers only expect there to be result rows
when SPI_execute returns SPI_OK_SELECT.

Seems we have three possibilities to fix this:

1. Alter SPI_execute to say SPI_OK_SELECT after executing a utility
statement that returns tuples.

2. Leave SPI_execute alone and fix the callers.

3. Invent a new result code (SPI_OK_UTILITY_TUPLES maybe?) to return
in this case ... which means changing both SPI_execute *and* the
callers. It would probably even propagate up to user code, since plperl
for one exposes the set of SPI result codes...

None of these seem especially attractive :-(. Any thoughts?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Fetter 2005-02-11 02:14:50 Re: Understanding EXPLAIN ANALYZE output
Previous Message Ed L. 2005-02-11 00:43:35 Re: Understanding EXPLAIN ANALYZE output