|
|
|
@ -1,12 +1,8 @@ |
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD html 4.01 transitional//EN"> |
|
|
|
|
|
|
|
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
|
|
|
|
<HTML> |
|
|
|
|
<!-- DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN" --> |
|
|
|
|
<!-- HTML --> |
|
|
|
|
|
|
|
|
|
<HEAD> |
|
|
|
|
<META name="generator" content="HTML Tidy, see www.w3.org"> |
|
|
|
|
|
|
|
|
|
<META http-equiv="Content-Type" content="text/html; charset=US-ASCII"> |
|
|
|
|
<TITLE>PostgreSQL FAQ</TITLE> |
|
|
|
|
</HEAD> |
|
|
|
|
|
|
|
|
@ -14,7 +10,7 @@ |
|
|
|
|
alink="#0000ff"> |
|
|
|
|
<H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1> |
|
|
|
|
|
|
|
|
|
<P>Last updated: Sat Oct 19 22:58:02 EDT 2002</P> |
|
|
|
|
<P>Last updated: Sun Oct 20 20:47:14 EDT 2002</P> |
|
|
|
|
|
|
|
|
|
<P>Current maintainer: Bruce Momjian (<A href= |
|
|
|
|
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR> |
|
|
|
@ -440,9 +436,8 @@ |
|
|
|
|
<I>Features</I> section above. We are built for reliability and |
|
|
|
|
features, though we continue to improve performance in every |
|
|
|
|
release. There is an interesting Web page comparing PostgreSQL to |
|
|
|
|
MySQL at <A href= "http://openacs.org/why-not-mysql.html"> |
|
|
|
|
|
|
|
|
|
http://openacs.org/why-not-mysql.html</A><BR> |
|
|
|
|
MySQL at <A href="http://openacs.org/philosophy/why-not-mysql.html"> |
|
|
|
|
http://openacs.org/philosophy/why-not-mysql.html</A><BR> |
|
|
|
|
|
|
|
|
|
<BR> |
|
|
|
|
</DD> |
|
|
|
@ -653,7 +648,7 @@ |
|
|
|
|
|
|
|
|
|
<P>If you are doing many <SMALL>INSERTs</SMALL>, consider doing |
|
|
|
|
them in a large batch using the <SMALL>COPY</SMALL> command. This |
|
|
|
|
is much faster than individual <SMALL>INSERTS.</SMALL> Second, |
|
|
|
|
is much faster than individual <SMALL>INSERTS</SMALL>. Second, |
|
|
|
|
statements not in a <SMALL>BEGIN WORK/COMMIT</SMALL> transaction |
|
|
|
|
block are considered to be in their own transaction. Consider |
|
|
|
|
performing several statements in a single transaction block. This |
|
|
|
@ -721,7 +716,7 @@ |
|
|
|
|
<P>If <I>postmaster</I> is running, start <I>psql</I> in one |
|
|
|
|
window, then find the <SMALL>PID</SMALL> of the <I>postgres</I> |
|
|
|
|
process used by <I>psql</I>. Use a debugger to attach to the |
|
|
|
|
<I>postgres</I> <SMALL>PID.</SMALL> You can set breakpoints in the |
|
|
|
|
<I>postgres</I> <SMALL>PID</SMALL>. You can set breakpoints in the |
|
|
|
|
debugger and issue queries from <I>psql</I>. If you are debugging |
|
|
|
|
<I>postgres</I> startup, you can set PGOPTIONS="-W n", then start |
|
|
|
|
<I>psql</I>. This will cause startup to delay for <I>n</I> seconds |
|
|
|
@ -759,7 +754,7 @@ |
|
|
|
|
maximum number of processes, <SMALL>NPROC;</SMALL> the maximum |
|
|
|
|
number of processes per user, <SMALL>MAXUPRC;</SMALL> and the |
|
|
|
|
maximum number of open files, <SMALL>NFILE</SMALL> and |
|
|
|
|
<SMALL>NINODE.</SMALL> The reason that PostgreSQL has a limit on |
|
|
|
|
<SMALL>NINODE</SMALL>. The reason that PostgreSQL has a limit on |
|
|
|
|
the number of allowed backend processes is so your system won't run |
|
|
|
|
out of resources.</P> |
|
|
|
|
|
|
|
|
@ -768,14 +763,13 @@ |
|
|
|
|
the MaxBackendId constant in |
|
|
|
|
<I>include/storage/sinvaladt.h</I>.</P> |
|
|
|
|
|
|
|
|
|
<H4><A name="3.9">3.9</A>) What are the <I>pgsql_tmp</I> |
|
|
|
|
directory?</H4> |
|
|
|
|
<H4><A name="3.9">3.9</A>) What is in the <I>pgsql_tmp</I> directory?</H4> |
|
|
|
|
|
|
|
|
|
<P>They are temporary files generated by the query executor. For |
|
|
|
|
example, if a sort needs to be done to satisfy an <SMALL>ORDER |
|
|
|
|
BY,</SMALL> and the sort requires more space than the backend's |
|
|
|
|
<I>-S</I> parameter allows, then temporary files are created to |
|
|
|
|
hold the extra data.</P> |
|
|
|
|
<P>This directory contains temporary files generated by the query |
|
|
|
|
executor. For example, if a sort needs to be done to satisfy an |
|
|
|
|
<SMALL>ORDER BY</SMALL> and the sort requires more space than the |
|
|
|
|
backend's <I>-S</I> parameter allows, then temporary files are created |
|
|
|
|
here to hold the extra data.</P> |
|
|
|
|
|
|
|
|
|
<P>The temporary files are usually deleted automatically, but might |
|
|
|
|
remain if a backend crashes during a sort. A stop and restart of the |
|
|
|
@ -815,7 +809,7 @@ |
|
|
|
|
|
|
|
|
|
<P>The entire query may have to be evaluated, even if you only want |
|
|
|
|
the first few rows. Consider using a query that has an <SMALL>ORDER |
|
|
|
|
BY.</SMALL> If there is an index that matches the <SMALL>ORDER |
|
|
|
|
BY</SMALL>. If there is an index that matches the <SMALL>ORDER |
|
|
|
|
BY</SMALL>, 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.</P> |
|
|
|
@ -955,22 +949,22 @@ |
|
|
|
|
</PRE> |
|
|
|
|
|
|
|
|
|
<P>When using wild-card operators such as <SMALL>LIKE</SMALL> or |
|
|
|
|
<I>~</I>, indexes can only be used in certain circumstances: |
|
|
|
|
<I>~</I>, indexes can only be used in certain circumstances:</P> |
|
|
|
|
<UL> |
|
|
|
|
<LI>The beginning of the search string must be anchored to the start |
|
|
|
|
of the string, i.e.:</LI> |
|
|
|
|
of the string, i.e. |
|
|
|
|
<UL> |
|
|
|
|
<LI><SMALL>LIKE</SMALL> patterns must not start with <I>%.</I></LI> |
|
|
|
|
<LI><SMALL>LIKE</SMALL> patterns must not start with <I>%</I>.</LI> |
|
|
|
|
<LI><I>~</I> (regular expression) patterns must start with |
|
|
|
|
<I>^.</I></LI> |
|
|
|
|
</UL> |
|
|
|
|
<I>^</I>.</LI> |
|
|
|
|
</UL></LI> |
|
|
|
|
<LI>The search string can not start with a character class, |
|
|
|
|
e.g. [a-e].</LI> |
|
|
|
|
<LI>Case-insensitive searches such as <SMALL>ILIKE</SMALL> and |
|
|
|
|
<I>~*</I> do not utilise indexes. Instead, use functional |
|
|
|
|
indexes, which are described in section <a href="#4.12">4.12</a>.</LI> |
|
|
|
|
<LI>The default <I>C</I> locale must be used during |
|
|
|
|
<i>initdb.</i></LI> |
|
|
|
|
<i>initdb</i>.</LI> |
|
|
|
|
</UL> |
|
|
|
|
<P> |
|
|
|
|
|
|
|
|
@ -1342,7 +1336,7 @@ BYTEA bytea variable-length byte array (null-byte safe) |
|
|
|
|
Because PostgreSQL loads database-specific system catalogs, it is |
|
|
|
|
uncertain how a cross-database query should even behave.</P> |
|
|
|
|
|
|
|
|
|
<P><I>/contrib/dblink</I> allows cross-database queries using |
|
|
|
|
<P><I>contrib/dblink</I> 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.</P> |
|
|
|
@ -1379,13 +1373,13 @@ BYTEA bytea variable-length byte array (null-byte safe) |
|
|
|
|
<H4><A name="4.28">4.28</A>) What encryption options are available? |
|
|
|
|
</H4> |
|
|
|
|
<UL> |
|
|
|
|
<LI><I>/contrib/pgcrypto</I> contains many encryption functions for |
|
|
|
|
<LI><I>contrib/pgcrypto</I> contains many encryption functions for |
|
|
|
|
use in <SMALL>SQL</SMALL> queries.</LI> |
|
|
|
|
<LI>The only way to encrypt transmission from the client to the |
|
|
|
|
server is by using <I>hostssl</I> in <I>pg_hba.conf</I>.</LI> |
|
|
|
|
<LI>Database user passwords are automatically encrypted when stored |
|
|
|
|
in version 7.3. In previous versions, you must enable the option |
|
|
|
|
<i>PASSWORD_ENCRYPTION</i> in <i>postgresql.conf</i>.</LI> |
|
|
|
|
<I>PASSWORD_ENCRYPTION</I> in <I>postgresql.conf</I>.</LI> |
|
|
|
|
<LI>The server can run using an encrypted file system.</LI> |
|
|
|
|
</UL> |
|
|
|
|
|
|
|
|
@ -1413,7 +1407,7 @@ BYTEA bytea variable-length byte array (null-byte safe) |
|
|
|
|
functions are fully supported in C, PL/PgSQL, and SQL. See the |
|
|
|
|
Programmer's Guide for more information. An example of a |
|
|
|
|
table-returning function defined in C can be found in |
|
|
|
|
contrib/tablefunc.</P> |
|
|
|
|
<I>contrib/tablefunc</I>.</P> |
|
|
|
|
|
|
|
|
|
<H4><A name="5.4">5.4</A>) I have changed a source file. Why does |
|
|
|
|
the recompile not see the change?</H4> |
|
|
|
|