Re: Understanding EXPLAIN ANALYZE output
От | Tom Lane |
---|---|
Тема | Re: Understanding EXPLAIN ANALYZE output |
Дата | |
Msg-id | 5014.1108084302@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Understanding EXPLAIN ANALYZE output (Michael Fuhr <mike@fuhr.org>) |
Ответы |
Re: Understanding EXPLAIN ANALYZE output
|
Список | pgsql-general |
Michael Fuhr <mike@fuhr.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
В списке pgsql-general по дате отправления: