Обсуждение: Execution Plan Cost

Поиск
Список
Период
Сортировка

Execution Plan Cost

От
Luis Vargas
Дата:
At the backend, I'm measuring the cost of executing (via SPI_execute_plan) 
the read-only plan of a simple query with no reference to tables. E.g. 
simpleplan(int) AS SELECT $1 > 5

Executing this plan via SPI_execute takes around 70% more time than 
directly executing the relevant operator function (int4gt) and using 
DatumGetBool. Can anyone give me any insight into what operations account 
for the extra execution time?

Thanks,

Luis Vargas


Re: Execution Plan Cost

От
Tom Lane
Дата:
Luis Vargas <Luis.Vargas@cl.cam.ac.uk> writes:
> At the backend, I'm measuring the cost of executing (via SPI_execute_plan) 
> the read-only plan of a simple query with no reference to tables. E.g. 
> simpleplan(int) AS SELECT $1 > 5

> Executing this plan via SPI_execute takes around 70% more time than 
> directly executing the relevant operator function (int4gt) and using 
> DatumGetBool.

Only that much?  I'd have expected it to be several hundred times
slower, considering that int4gt is an utterly trivial function and
executor startup/shutdown is a fairly heavyweight operation.
        regards, tom lane


Re: Execution Plan Cost

От
Luis Vargas
Дата:
The read-only plan of the query (SELECT $1 > 5) is prepared, so there is
not parsing or planning. Any insight into what operations account for the
executor startup/shutdown time?

Thanks a lot,

Luis Vargas


On May 8 2008, Tom Lane wrote:

>Luis Vargas <Luis.Vargas@cl.cam.ac.uk> writes:
>> At the backend, I'm measuring the cost of executing (via
>> SPI_execute_plan) the read-only plan of a simple query with no reference
>> to tables. E.g. simpleplan(int) AS SELECT $1 > 5
>
>> Executing this plan via SPI_execute takes around 70% more time than
>> directly executing the relevant operator function (int4gt) and using
>> DatumGetBool.
>
>Only that much?  I'd have expected it to be several hundred times
>slower, considering that int4gt is an utterly trivial function and
>executor startup/shutdown is a fairly heavyweight operation.
>
>            regards, tom lane
>

--
**************************************************************************
PhD Research Student
Room FE04, Computer Laboratory, University of Cambridge
Office: +44 (0) 1223 763 776       Mobile: +44 (0) 7767 086 105
MSN Messenger: luis_herring@hotmail.com
**************************************************************************