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 <[EMAIL PROTECTED]> writes:
At the backe
Luis Vargas <[EMAIL PROTECTED]> 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
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 functi
On Wed, 2007-01-03 at 19:44 +, alfranio correia junior wrote:
> I have some questions on execution plans.
>
> When are the following plans used ?
>
> nodeFunctionscan.c
When there is a Set Returning Function emitting tuples.
> nodeTidscan.c
When there is a query that accesses data usin
Hi,
I have some questions on execution plans.
When are the following plans used ?
nodeFunctionscan.c nodeTidscan.c
In particular, is the plan nodeBitmapHeapscan.c always used along with
the nodeBitmapIndexscan.c ?
Please, let me know if there is a previous thread on this subject or any
d