Postgres Pro
Downloads
Home   >   mailing lists

Thread: Execution Plan Cost

Execution Plan Cost

From
Luis Vargas
Date:
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

From
Tom Lane
Date:
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

From
Luis Vargas
Date:
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
**************************************************************************