Re: [HACKERS] Execution Plan Cost
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 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: [EMAIL PROTECTED] ** -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Execution Plan Cost
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 > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Execution Plan Cost
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Execution Plan
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 using a direct TID, e.g. WHERE ctid = '(5,12)' this is most frequently found in calls made through the ODBC driver when it uses its client-side implementation of updateable cursors. This is only used these days when we have a multi-statement request, so is mostly unused now. > In particular, is the plan nodeBitmapHeapscan.c always used along with > the nodeBitmapIndexscan.c ? Yes > Please, let me know if there is a previous thread on this subject or any > document available. Try src/backend/executor readme and code comments, plus the main docs are reasonable. Documentation always welcome. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Execution Plan
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 document available. Best regards, Alfranio. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
