If you are doing many INSERTs, consider doing them in a large batch using the COPY command. This ! is much faster than individual INSERTS. Second, statements not in a BEGIN WORK/COMMIT transaction block are considered to be in their own transaction. Consider performing several statements in a single transaction block. This --- 648,654 ----
If you are doing many INSERTs, consider doing them in a large batch using the COPY command. This ! is much faster than individual INSERTS. Second, statements not in a BEGIN WORK/COMMIT transaction block are considered to be in their own transaction. Consider performing several statements in a single transaction block. This *************** *** 721,727 ****
If postmaster is running, start psql in one window, then find the PID of the postgres process used by psql. Use a debugger to attach to the ! postgres PID. You can set breakpoints in the debugger and issue queries from psql. If you are debugging postgres startup, you can set PGOPTIONS="-W n", then start psql. This will cause startup to delay for n seconds --- 716,722 ----
If postmaster is running, start psql in one window, then find the PID of the postgres process used by psql. Use a debugger to attach to the ! postgres PID. You can set breakpoints in the debugger and issue queries from psql. If you are debugging postgres startup, you can set PGOPTIONS="-W n", then start psql. This will cause startup to delay for n seconds *************** *** 759,765 **** maximum number of processes, NPROC; the maximum number of processes per user, MAXUPRC; and the maximum number of open files, NFILE and ! NINODE. The reason that PostgreSQL has a limit on the number of allowed backend processes is so your system won't run out of resources.
--- 754,760 ---- maximum number of processes, NPROC; the maximum number of processes per user, MAXUPRC; and the maximum number of open files, NFILE and ! NINODE. The reason that PostgreSQL has a limit on the number of allowed backend processes is so your system won't run out of resources. *************** *** 768,781 **** the MaxBackendId constant in include/storage/sinvaladt.h. !They are temporary files generated by the query executor. For ! example, if a sort needs to be done to satisfy an ORDER ! BY, and the sort requires more space than the backend's ! -S parameter allows, then temporary files are created to ! hold the extra data.
The temporary files are usually deleted automatically, but might remain if a backend crashes during a sort. A stop and restart of the --- 763,775 ---- the MaxBackendId constant in include/storage/sinvaladt.h.
!This directory contains temporary files generated by the query ! executor. For example, if a sort needs to be done to satisfy an ! ORDER BY and the sort requires more space than the ! backend's -S parameter allows, then temporary files are created ! here to hold the extra data.
The temporary files are usually deleted automatically, but might remain if a backend crashes during a sort. A stop and restart of the *************** *** 815,821 ****
The entire query may have to be evaluated, even if you only want the first few rows. Consider using a query that has an ORDER ! BY. If there is an index that matches the ORDER BY, PostgreSQL may be able to evaluate only the first few records requested, or the entire query may have to be evaluated until the desired rows have been generated.
--- 809,815 ----The entire query may have to be evaluated, even if you only want the first few rows. Consider using a query that has an ORDER ! BY. If there is an index that matches the ORDER BY, PostgreSQL may be able to evaluate only the first few records requested, or the entire query may have to be evaluated until the desired rows have been generated.
*************** *** 955,976 ****When using wild-card operators such as LIKE or ! ~, indexes can only be used in certain circumstances:
--- 949,970 ----
When using wild-card operators such as LIKE or ! ~, indexes can only be used in certain circumstances:
*************** *** 1341,1347 **** Because PostgreSQL loads database-specific system catalogs, it is uncertain how a cross-database query should even behave.
!/contrib/dblink allows cross-database queries using function calls. Of course, a client can make simultaneous connections to different databases and merge the results on the client side.
--- 1335,1341 ---- Because PostgreSQL loads database-specific system catalogs, it is uncertain how a cross-database query should even behave. !contrib/dblink allows cross-database queries using function calls. Of course, a client can make simultaneous connections to different databases and merge the results on the client side.
*************** *** 1378,1390 ****