Última actualización: Tue Mar 21 16:09:11 EST 2000
Encargado Actual de su mantenimiento: Bruce Momjian (pgman@candle.pha.pa.us)
La versión más reciente de este documento puede visualizarse en el sitio web de postgreSQL, http://www.postgresql.org/.
Las preguntas específicas sobre Linux son contestadas en http://www.PostgreSQL.org/docs/faq-linux.html.
Las preguntas específicas sobre Irix son contestadas en http://www.PostgreSQL.org/docs/faq-irix.html.
Las preguntas específicas sobre HPUX son contestadas en http://www.PostgreSQL.org/docs/faq-hpux.shtml.
1.1) ¿Qué es PostgreSQL?
1.2) ¿Cuál es el Copyright de PostgreSQL?
1.3) ¿En qué plataformas Unix corre PostgreSQL?
1.4) ¿Qué adaptaciones no unix están disponibles?
1.5) ¿Dónde puedo conseguir PostgreSQL?
1.6) ¿Dónde puedo conseguir asistencia para PostgreSQL?
1.7) ¿Cuál es la última versión de PostgreSQL?
1.8) ¿Qué documentación existe sobre PostgreSQL?
1.9) ¿Cómo me informo de nuevos errores o características faltantes?
1.10) ¿Cómo puedo aprender SQL?
1.11) ¿Está PostgreSQL certificado Y2K?
1.12) ¿Cómo puedo unirme al equipo de desarrollo?
1.13) ¿Cómo envío informes sobre fallos de funcionamiento?
1.14) ¿Cómo puede compararse PostgreSQL a otros DBMS's?
2.1) ¿Existen controladores ODBC para PostgreSQL?
2.2) ¿Que herramientas hay disponibles para conectar PostgreSQL con páginas Web?
2.3) ¿Tiene PostgreSQL una interfase gráfica? ¿Y generador de informes? ¿E interfase para lenguajes de consulta empotrados?
2.4) ¿Que lenguajes hay disponibles para comunicar con PostgreSQL?
3.1) ¿Por qué initdb falla?
3.2) ¿Cómo puedo instalar PostgreSQL en algún sitio distinto de /usr/local/pgsql?
3.3) Cuándo inicio el postmaster, Obtengo un Llamada errónea del sistema o un mensaje core dumped . ¿Por qué?
3.4) Cuándo intento iniciar postmaster, Obtengo un error IpcMemoryCreate errors3. ¿Por qué?
3.5) Cuándo intento iniciar postmaster, Obtengo un error IpcSemaphoreCreate. ¿Por qué?
3.6) ¿Cómo me prevengo del acceso de otros hosts a mi base de datos PostgreSQL?
3.7) ¿Por qué no puedo conectarme a mi base de datos desde otra máquina?
3.8) ¿Por qué no puedo acceder a la base de datos como usuario root?
3.9) Todos mis servidores fallan bajo el acceso concurrente a tablas ¿Por qué?
3.10) ¿Cómo afino el motor de base de datos para mejorar el rendimiento?
3.11) ¿Qué características de depuración están disponibles en PostgreSQL?
3.12) Obtengo 'Sorry, too many clients' cuando intento conectarme. ¿Por qué?
3.13) ¿Qué son los ficheros pg_psort.XXX en mi directorio de base de datos?
3.14) ¿Cómo configuro el pg_group?
4.1) The system seems to be confused about commas, decimal points, and date formats.
4.2) What is the exact difference between binary cursors and normal cursors?
4.3) How do I select only the first few rows of a query?
4.4) How do I get a list of tables, or other things I can see in psql?
4.5) How do you remove a column from a table?
4.6) What is the maximum size for a row, table, database?
4.7) How much database disk space is required to store data from a typical flat file?
4.8) How do I find out what indices or operations are defined in the database?
4.9) My queries are slow or don't make use of the indexes. Why?
4.10) How do I see how the query optimizer is evaluating my query?
4.11) What is an R-tree index?
4.12) What is Genetic Query Optimization?
4.13) How do I do regular expression searches and case-insensitive regexp searching?
4.14) In a query, how do I detect if a field is NULL?
4.15) What is the difference between the various character types?
4.16.1) How do I create a serial/auto-incrementing field?
4.16.2) How do I get the value of a serial insert?
4.16.3) Wouldn't use of currval() and nextval() lead to a race condition with other concurrent backend processes?
4.17) What is an oid? What is a tid?
4.18) What is the meaning of some of the terms used in PostgreSQL?
4.19) Why do I get the error "FATAL: palloc failure: memory exhausted?"
4.20) How do I tell what PostgreSQL version I am running?
4.21) My large-object operations get invalid large obj descriptor. Why?
4.22) How do I create a column that will default to the current time?
4.23) Why are my subqueries using IN so slow?
5.1) He escrito una función de usuario. Cuando la ejecuto con psql, ¿por qué provoca un volcado del núcleo (dumps core)?
5.2) ¿Que significa el mensaje: NOTICE:PortalHeapMemoryFree: 0x402251d0 not in alloc set! ?
5.3) ¿Como puede contribuir aportando algunos nuevos tipos y funciones a PostgreSQL?
5.4) ¿Cómo puede escribir una función en C que devuelva un par de valores?
5.5) He cambiado un fichero fuente. ¿Por qué si recompilo no se observa el cambio??
PostgreSQL es una mejora del sistema gestor de bases de datos POSTGRES, un prototipo de investigación de DBMS de nueva generación. Mientras PostgreSQL mantiene los potentes modelos de datos y riqueza de tipos de POSTGRES, reemplaza el lenguaje de consulta PostQuel con un subjuego extendido de SQL. PostgreSQL es gratis y las fuentes son accesibles públicamente.
El desarrollo de PostgreSQL está siendo realizado por un equipo de desarrolladores de Internet suscritos a la lista de correo de PostgreSQL. El coordinador actual es Marc G. Fournier (scrappy@postgreSQL.org). (Véase abajo para unirse al grupo). Este equipo es el actual responsable de todo el desarrollo actual y futuro de PostgreSQL.
Los autores de PostgreSQL 1.01 fueron Andrew Yu y Jolly Chen. Muchos otros han contribuido a la adaptación a otras plataformas, pruebas, depuración y mejoras del código. El código original de Postgres, del cual deriva PostgreSQL, fue el esfuerzo de muchos estudiantes graduados, estudiantes no graduados y programadores de base trabajando bajo la dirección del profesor Michael Stonebraker en la Universidad de Berkeley (California).
El nombre original del software en Berkeley fue Postgres. Cuando se le añadió la funcionalidad SQL en 1995, su nombre se cambió a Postgres95. El nombre volvió a ser cambiado a finales de 1996 a PostgreSQL.
Se pronuncia Post-Gres-Q-L.
PostgreSQL está sujeto al siguiente COPYRIGHT.
Sistema Gestor de Bases de Datos PostgreSQL
Porciones copyright (c) 1996-2000, PostgreSQL, Inc Porciones Copyright (c) 1994-6 Regentes de la Universidad de California
Se permite el uso, copia, modificación, y distribución de este software y su documentación para cualquier propósito, sin pago ni acuerdo previo escrito, a condición de que el anterior aviso de copyright, este párrafo y los dos siguientes aparezcan en todas las copias.
EN NINGUN CASO LA UNIVERSIDAD DE CALIFORNIA SE RESPONSABILIZARA DE DAÑOS DIRECTOS, INDIRECTOS, ACCIDENTALES O CONSECUENCIALES, INCLUYENDO PERDIDA DE BENEFICIOS, DERIVADOS DEL USO DE ESTE SOFTWARE Y SU DOCUMENTACION, INCLUSO SI LA UNIVERSIDAD DE CALIFORNIA HA SIDO AVISADA DE LA POSIBILIDAD DE TALES DAÑOS.
LA UNIVERSIDAD DE CALIFORNIA ESPECIFICAMENTE RENUNCIA A LA CONCESIÓN DE CUALQUIER GARANTIA, INCLUYENDO PERO NO LIMITANDOSE A LAS GARANTIAS IMPLICITAS DE COMERCIALIDAD Y AJUSTE PARA UN PROPOSITO PARTICULAR. EL SOFTWARE ES SUMINISTRADO "TAL CUAL", Y LA UNIVERSIDAD DE CALIFORNIA NO ESTA OBLIGADA A SUMINISTRAR MANTENIMIENTO, SOPORTE, ACTUALIZACIONES, MEJORAS O MODIFICACIONES SOBRE EL MISMO.
Los autores han compilado y probado PostgreSQL en las siguientes plataformas (algunas de estas compilaciones requieren gcc):
Es posible compilar las librerías libpq, psql y otros interfaces y binarios para su ejecución en MS Windows. En este caso, el cliente se ejecuta en MS Windows, y se comunica a través de TCP/IP con un servidor que está funcionando en una de las plataformas Unix soportadas.
El fichero win31.mak se incluye en la distribución para la compilación de las librerías libpq y psql en Win32.
El servidor de bases de datos funciona actualmente en Windows NT usando la librería de adaptación Cygnus Unix/NT. Véase pgsql/doc/README.NT en la distribución.
También existe una página web en http://www.freebsd.org/~kevlo/postgres/portNT.html Existe también otra adaptación usando U/Win en http://surya.wipro.com/uwin/ported.html
El sitio ftp primario anónimo para PostgreSQL es ftp://ftp.postgreSQL.org/pub
Para sitios espejo, véase el sitio web principal.
No hay asistencia oficial para PostgreSQL desde la Universidad de Berkeley, California. Se mantiene a través del esfuerzo de voluntarios.
La lista de correo principal es: pgsql-general@postgreSQL.org. Está disponible para la discusión de asuntos referentes a PostgreSQL. Para suscribirse, envíe un e-mail con las siguientes líneas en el cuerpo (no en el sujeto)
subscribe end
to pgsql-general-request@postgreSQL.org.
Asimismo existe una lista de compendios de mensajes. Para suscribirse a ella, envíe un e-mail a: pgsql-general-digest-request@postgreSQL.org con las siguientes líneas en el cuerpo del mensaje:
subscribe end
Los compendios se envían a los miembros de esta lista en el momento que la lista principal ha recibido 30k de mensajes aproximadamente.
La lista de correo de errores también está disponible. Para suscibirse, envíe un e-mail a bugs-request@postgreSQL.org con las siguientes líneas en el cuerpo del mensaje:
subscribe end
También está disponible una lista de correo para discusión de desarrolladores. Para suscibirse, envíe un e-mail a hackers-request@postgreSQL.org con las siguientes líneas en el cuerpo del mensaje:
subscribe end
Listas de correo adicionales e información acerca de PostgreSQL puede ser encontrada en la página web principal de PostgreSQL en:
http://postgresql.org/
También existe un canal IRC en EFNet, el canal #PostgreSQL. Yo uso el comando unix irc -c '#PostgreSQL' "$USER" irc.phoenix.net
Existe asistencia comercial disponible para PostgreSQL en http://www.pgsql.com/
La última versión de PostgreSQL es la 7.0.
Planeamos tener versiones de orden mayor cada cuatro meses.
Varios manuales, páginas man, y algunos pequeños ejemplos de texto se incluyen en la distribución. Véase el directorio /doc. También se puede consultar el manual on-line en http://www.postgresql.org/docs/postgres en la distribución.
psql tiene algunos comandos \d para mostrar información acerca de tipos, operadores, funciones, agregados, etc.
El sitio web contiene aún más documentación.
PostgreSQL soporta un subjuego extendido de SQL-92. Véase nuestro TODO para una lista de errores conocidos, características faltantes y planes futuros.
Existe un bonito tutorial en http://w3.one.net/~jhoffman/sqltut.htm y en http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM
Otro es "Teach Yourself SQL in 21 Days, Second Edition" en http://members.tripod.com/er4ebus/sql/index.htm
Muchos de nuestros usuarios prefieren The Practical SQL Handbook, Bowman et al., Addison Wesley. Otros, Lan Times Guide to SQL, Groff et al., Osborne McGraw-Hill.
Si, manejamos con fiabilidad fechas anteriores y posteriores al año 2000.
Primero, descargue los últimos fuentes y lea la documentación para desarrolladores de PostgreSQL Developers en nuestro sitio web, o en la distribución. Segundo, suscríbase a las listas de correo pgsql-hackers y pgsql-patches. Tercero, envíe patches de alta calidad a apgsql-patches.
Existe sobre una docena de personas que tienen privilegios COMMIT en el archivo PostgreSQL CVS. Todos ellos enviaron muchos patches de alta calidad que supusieron quebraderos de cabeza a la hora de ser continuados por los compromisarios existentes, y no dudamos sobre la calidad de los patches que enviaron.
Rellene el fichero "bug-template" y envíelo a: bugs@postgreSQL.org
También compruebe nuestro sitio ftp ftp://ftp.postgreSQL.org/pub para ver si hay una versión más reciente de PostgreSQL o patches.
Existen varias formas de comparar el software: características, rendimiento, fiabilidad, asistencia y precio.
Hay dos controladores ODBC disponibles, PostODBC y OpenLink ODBC.
PostODBC se incluye con la distribución. Puede encontrarse más información en: http://www.insightdist.com/psqlodbc
OpenLink ODBC puede encontrarse en http://www.openlinksw.com/. Funciona con los programas clientes ODBC, por lo que puede tener disponible un driver ODBC para PostgreSQL ODBC para cualquier plataforma cliente (Win, Mac, Unix, VMS).
Este producto esta probablemente a la venta para quien necesite soporte profesional de calidad, pero puede encontrarse una versión freeware. Consultar postgres95@openlink.co.uk.
Puede encontrarse una buena introducción a las páginas Web con dorsal de base de datos en: http://www.webtools.com/
Hay otra en: http://www.phone.net/home/mwm/hotlist/
para integración con Web, PHP es una excelente interfase. Está en: http://www.php.net/
PHP es fantástico para cosas simples, pero para casos más complejos, puede usarse la interfase con perl y CGI.pm.
Una pasarela WWW basada en WDB usando perl puede descargarse de http://www.eol.ists.ca/~dunlop/wdb-p95
Tenemos una buena interfase gráfica llamada pgaccess, que se incluye como parte de la distribución. Pgaccess tiene también un generador de informes. Su página Web está en http://www.flex.ro/pgaccess
También se incluye ecpg, que es una interfase empotrada para el lenguaje de consultas SQL en C.
Tenemos:
WARN:heap_modifytuple: repl is \ 9, este es el problema.) El camino más simple es especificar la --opción de prefijo cuando ejecutas configure. Si tu olvidaste hacerlo cuando tú puedes editar Makefile.global y cambiar POSTGRESDIR por consiguiente, o crear un Makefile propio y definir POSTGRESDIR aquí.
Esto puede ser varios problemas, pero lo primero que hay que comprobar es ver si tenemos instaladas las extensiones del system V en nuestro núcleo. PostgreSQL requiere que el núcleo soporte la memoria compartida y los semáforos.
No tienes configurado correctamente la memoria compartido en el núcleo o necesitas agrandar la memoria compartida disponible en el núcleo. La cantidad exacta que necesitas depende de tu arquitectura y de cuantos buffers y procesos backend configures para ejecutar postmaster. Para muchos sistemas, con el número por defecto de buffers y procesos, necesitas un mínimo de ~1MB.
Si el mensaje de error es IpcSemaphoreCreate: semget failed (Sin espacio en el dispositivo) entonces tu núcleo no está configurado con suficientes semáforos. Postgres necesita un semáforo para cada proceso backend potencial. Una solución temporal es comenzar postmaster con un número límite más pequeño de procesos backend. Usa -N con un parámetro más pequeño que el 32 por defecto. Una solución permanente es elevar los parámetros del tu núcleo SEMMNS y SEMMNI.
Si el mensaje de error es algo parecido, tu no debes tener el soporte de semáforo configurado del todo en tu núcleo.
Por defecto, PostgreSQL sólo permite conexiones desde la máquina local usando los dominios sockets. Otras maquinas no serán capaces de conectarse sin que tú añadas la opción -i en postmaster, y habilitas la autenticación basada en el host modificando el fichero $PGDATA/pg_hba.conf .Por consiguiente esto permitirá las conexiones TCP/IP.
La configuración por defecto permite sólo conexiones mediante el dominio socket de unix desde la máquina local. Para habilitar las conexiones TCP/IP, hay que tener cuidad de que postmaster haya sido iniciado con la opción -i, y añadir la entrada apropiado de host en el fichero pgsql/data/pg_hba.conf. Mira las páginas del manual de pg_hba.conf.
Tú no debes crear usuarios de bases de datos con el identificador de usuario 0 (root) Estos no podrán acceder a la base de datos. Es una precaución de seguridad debido a la capacidad de cualquier usuario de poder enlazar dinámicamente módulos objeto al motor de base.
Este problema puede ser causado por el núcleo que no esté configurado para soportar semáforos.
Ciertamente, los índices pueden acelerar las consultas. El comando EXPLAIN habilita que tú veas como PostgreSQL interpreta tu consulta, y que índices está usando.
Si estás haciendo muchos INSERTs, considera hacerlo en un gran proceso por lotes usando el comando COPY. Esto es más rápido que un solo INSERTS individual. Segundo, la sentencia que no esta en un bloque de transacción BEGIN WORK/COMMIT se considera que esta en su propia transacción. Considera la utilización de varias sentencias en un mismo bloque transaccional. Esto reduce el gasto transaccional. También considera quitar o recrear índices cuando las modificaciones de los datos son grandes.
Hay bastantes cosas para afinar que puedes hacer. Puedes deshabilitar fsync() al iniciar el postmaster con las opciones -o -F. Esto previene fsync() del vaciado del disco después de cada transacción.
También puedes usar la opción de postmaster -B para incrementar el número de buffers de memoria compartida usados por los procesos backend. Si haces que este parámetro sea muy alto, postmaster nunca inicia porque has excedido el límite de espacio de memoria compartida del núcleo. Cada buffer es de 8K y por defecto hay 64 buffers.
Tú puedes también usa la opción del backend -S para incrementar la cantidad máxima de memoria usada por los procesos backend para las ordenaciones temporales. El valor de -S está medido en kilobytes, y por defecto es de 512 (pe, 512K).
También puedes usar el comando CLUSTER para agrupar los datos en una tabla base para indexarla. Mira las páginas del manual cluster(l) para más detalles.
PostgreSQL tiene varias caracteristicas que dan información del estado que te pueden ser valiosas para depurar.
Primero, ejecutando configure con la opción--enable-cassert, muchos assert() controlan el progreso de los backend y para el programa cuando ocurre algo inesperado.
Ambos, postmaster y postgres tienen varias opciones de depuración disponibles. Primero, cuando tú inicias postmaster, ten cuidado de enviar la salida standard y la de error a un fichero de log, como:
cd /usr/local/pgsql ./bin/postmaster >server.log 2>&1 &
Esto pondrá varios ficheros de log en el nivel más alto del directorio de PostgreSQL. Este fichero contiene información útil acerca de los problemas o errores encontrados por el servidor. Postmaster tiene la opción -d que permite aun más información detallada para ser informada. La opción -d coge el número que especifica el nivel de depuración. Es peligroso un valor alto del nivel de depuración ya que genera grandes ficheros de log.
Tú puedes actualmente ejecutar backend de postgres desde la línea de comandos, y escribir tu sentencia SQL directamente. Esto sólo se recomienda si el propósito es depurar. Notar que la terminación de nueva línea de la consulta, no es el punto y coma. Si tú has compilado con símbolos de depuración, tú puedes utilizar el depurador para ver lo que está pasando. Debido a que el backend no fue iniciado por el postmaster, este no se ejecuta en un mismo entorno y los problemas de interacción entre backend no pueden ser duplicado. Algunos depuradores pueden adjuntar a un backend que ya está ejecutándose; que es el método más conveniente para diagnosticar los problemas en un entorno normal multi-backend.
El programa postgres tiene las opciones -s, -A, y -t que pueden ser muy útiles para la depuración y la medida del rendimiento.
Tú también puedes compilar con el perfil para ver que funciones están usando tiempo de ejecución. Los ficheros del perfil de los backend estarán depositados en el directorio pgsql/data/base/dbname. El perfil del cliente estará localizado en el directorio actual del cliente.
Tu necesitas aumentar el límite del posmaster para cantidad de procesos backend concurrentes que puede iniciar.
En Postgres 6.5 y superiores, el límite por defecto es 32 procesos. Tú puedes aumentarlo reiniciando el postmaster con el más conveniente valor -N. Con la configuración por defecto tú puedes poner -N más grande que 1024; si tú necesitas más, aumenta MAXBACKENDS en include/config.h y reconstruirlo. Puedes poner el valor -N por defecto en tiempo de configuración, si te gusta, usando el modificador de configuración --with-maxbackends.
Notar que si incrementas -N más de 32, debes también incrementar -B por encima del 64 que es por defecto; -B debe ser dos veces como mínimo -N, y probablemente debe ser más para un mejor rendimiento. Para un gran número de procesos backend, también es probable buscar si necesitas incrementar varios parámetros de configuración del núcleo de Unix. Cosas a mirar incluyen la máxima longitud de los bloques de memoria compartida, SHMMAX, el número máximo de semáforos, SEMMNS y SEMMNI, el número máximo de procesos, NPROC, el número máximo de procesos por usuario, MAXUPRC, y el número máximo de ficheros abiertos, NFILE y NINODE. La razón por la que Postgres tiene limitado el número de procesos backend permitidos es que puedes asegurar que tu sistema no funcionará sin recursos.
En las versiones superiores a la 6.5 de Postgres, el número máximo de backends eran 64, y el cambio requería la reconstrucción después de alterar la constante MaxBackendId en include/storage/sinvaladt.h.
Hay ficheros temporales generados por el ejecutor de consultas. Por ejemplo, si una ordenación necesita para realizarse satisfacer un ORDER BY, y la ordenación requiere más espacio del que el parámetro -S permite, entonces los ficheros temporales son creados para contener los datos extras.
Los ficheros temporales se deberían borrar automáticamente, pero podría ser que no si durante una ordenación el proceso falla. Si no hay transacciones ejecutándose en este mismo momento, es seguro borrar los ficheros pg_tempNNN.NN.
Actualmente, no existe una interface fácil, para configurar los grupos de usuarios. Tienes que insertar/modificar explícitamente la tabla pg_group. Por ejemplo:
jolly=> insert into pg_group (groname, grosysid, grolist)
jolly=> values ('posthackers', '1234', '{5443, 8261}');
INSERT 548224
jolly=> grant insert on foo to group posthackers;
CHANGE
jolly=>
Los campos de pg_group son:
Check your locale configuration. PostgreSQL uses the locale settings of the user that ran the postmaster process. There are postgres and psql SET commands to control the date format. Set those accordingly for your operating environment.
See the DECLARE manual page for a description.
See the FETCH manual page, or use SELECT ... LIMIT....
The entire query may have to be evaluated, even if you only want the first few rows. Consider 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.
You can read the source code for psql, file pgsql/src/bin/psql/psql.c. It contains SQL commands that generate the output for psql's backslash commands. You can also start psql with the -E option so that it will print out the queries it uses to execute the commands you give.
We do not support ALTER TABLE DROP COLUMN, but do this:
SELECT ... -- select all columns but the one you want to remove INTO TABLE new_table FROM old_table; DROP TABLE old_table; ALTER TABLE new_table RENAME TO old_table;
Rows are limited to 8K bytes, but this can be changed by editing include/config.h and changing BLCKSZ. To use attributes larger than 8K, you can also use the large object interface.
Rows do not cross 8k boundaries so a 5k row will require 8k of storage.
Table and database sizes are unlimited. There are many databases that are tens of gigabytes, and probably some that are hundreds.
A Postgres database can require about six and a half times the disk space required to store the data in a flat file.
Consider a file of 300,000 lines with two integers on each line. The flat file is 2.4MB. The size of the PostgreSQL database file containing this data can be estimated at 14MB:
36 bytes: each row header (approximate)
+ 8 bytes: two int fields @ 4 bytes each
+ 4 bytes: pointer on page to tuple
----------------------------------------
48 bytes per row
The data page size in PostgreSQL is 8192 bytes (8 KB), so:
8192 bytes per page
------------------- = 171 rows per database page (rounded up)
48 bytes per row
300000 data rows
-------------------- = 1755 database pages
171 rows per page
1755 database pages * 8192 bytes per page = 14,376,960 bytes (14MB)
Indexes do not contain as much overhead, but do contain the data that is being indexed, so they can be large also.
psql has a variety of backslash commands to show such information. Use \? to see them.
Also try the file pgsql/src/tutorial/syscat.source. It illustrates many of the SELECTs needed to get information from the database system tables.
PostgreSQL does not automatically maintain statistics. One has to make an explicit VACUUM call to update the statistics. After statistics are updated, the optimizer knows how many rows in the table, and can better decide if it should use indices. Note that the optimizer does not use indices in cases when the table is small because a sequential scan would be faster.
For column-specific optimization statistics, use VACUUM ANALYZE. VACUUM ANALYZE is important for complex multi-join queries, so the optimizer can estimate the number of rows returned from each table, and choose the proper join order. The backend does not keep track of column statistics on its own, so VACUUM ANALYZE must be run to collect them periodically.
Indexes are usually not used for ORDER BY operations: a sequential scan followed by an explicit sort is faster than an indexscan of all tuples of a large table, because it takes fewer disk accesses.
When using wild-card operators such as LIKE or ~, indices can only be used if the beginning of the search is anchored to the start of the string. So, to use indices, LIKE searches should not begin with %, and ~(regular expression searches) should start with ^.
See the EXPLAIN manual page.
An r-tree index is used for indexing spatial data. A hash index can't handle range searches. A B-tree index only handles range searches in a single dimension. R-tree's can handle multi-dimensional data. For example, if an R-tree index can be built on an attribute of type point, the system can more efficient answer queries like select all points within a bounding rectangle.
The canonical paper that describes the original R-Tree design is:
Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial Searching." Proc of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
You can also find this paper in Stonebraker's "Readings in Database Systems"
Builtin R-Trees can handle polygons and boxes. In theory, R-trees can be extended to handle higher number of dimensions. In practice, extending R-trees require a bit of work and we don't currently have any documentation on how to do it.
The GEQO module in PostgreSQL is intended to solve the query optimization problem of joining many tables by means of a Genetic Algorithm (GA). It allows the handling of large join queries through non-exhaustive search.
For further information see the documentation.
The ~ operator does regular-expression matching, and ~* does case-insensitive regular-expression matching. There is no case-insensitive variant of the LIKE operator, but you can get the effect of case-insensitive LIKE with this:
WHERE lower(textfield) LIKE lower(pattern)
You test the column with IS NULL and IS NOT NULL.
Type Internal Name Notes -------------------------------------------------- "char" char 1 character CHAR(#) bpchar blank padded to the specified fixed length VARCHAR(#) varchar size specifies maximum length, no padding TEXT text length limited only by maximum row length BYTEA bytea variable-length array of bytes
You will see the internal name when examining system catalogs and in some error messages.
The last four types above are "varlena" types (i.e. the first four bytes are the length, followed by the data). char(#) allocates the maximum number of bytes no matter how much data is stored in the field. text, varchar(#), and bytea all have variable length on the disk, and because of this, there is a small performance penalty for using them. Specifically, the penalty is for access to all columns after the first column of this type.
PostgreSQL supports SERIAL data type. It auto-creates a sequence and index on the column. For example, this...
CREATE TABLE person ( id SERIAL, name TEXT );
...is automatically translated into this...
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);
CREATE UNIQUE INDEX person_id_key ON person ( id );
See the create_sequence manual page for more information about sequences. You can also use each row's oid field as a unique value. However, if you need to dump and reload the database, you need to use pg_dump's -o option or COPY WITH OIDS option to preserve the oids.
For more details, see Bruce Momjian's chapter on Numbering Rows.
Probably the simplest approach is to to retrieve the next SERIAL value from the sequence object with the nextval() function before inserting and then insert it explicitly. Using the example table in 4.16.1, that might look like this:
$newSerialID = nextval('person_id_seq');
INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
You would then also have the new value stored in $newSerialID for use in other queries (e.g., as a foreign key to the person table). Note that the name of the automatically-created SEQUENCE object will be named <table>_<serialcolumn>_seq, where table and serialcolumn are the names of your table and your SERIAL column, respectively.
Similarly, you could retrieve the just-assigned SERIAL value with the currval() function after it was inserted by default, e.g.,
INSERT INTO person (name) VALUES ('Blaise Pascal');
$newID = currval('person_id_seq');
Finally, you could use the oid returned from the INSERT statement to lookup the default value, though this is probably the least portable approach. In perl, using DBI with Edmund Mergl's DBD::Pg module, the oid value is made available via $sth->{pg_oid_status} after $sth->execute().
No. That has been handled by the backends.
Oids are PostgreSQL's answer to unique row ids. Every row that is created in PostgreSQL gets a unique oid. All oids generated during initdb are less than 16384 (from backend/access/transam.h). All user-created oids are equal or greater that this. By default, all these oids are unique not only within a table, or database, but unique within the entire PostgreSQL installation.
PostgreSQL uses oids in its internal system tables to link rows between tables. These oids can be used to identify specific user rows and used in joins. It is recommended you use column type oid to store oid values. See the sql(l) manual page to see the other internal columns. You can create an index on the oid field for faster access.
Oids are assigned to all new rows from a central area that is used by all databases. If you want to change the oid to something else, or if you want to make a copy of the table, with the original oid's, there is no reason you can't do it:
CREATE TABLE new_table(old_oid oid, mycol int);
SELECT INTO new SELECT old_oid, mycol FROM old;
COPY new TO '/tmp/pgtable';
DELETE FROM new;
COPY new WITH OIDS FROM '/tmp/pgtable';
Tids are used to identify specific physical rows with block and offset values. Tids change after rows are modified or reloaded. They are used by index entries to point to physical rows.
Some of the source code and older documentation use terms that have more common usage. Here are some:
It is possible you have run out of virtual memory on your system, or your kernel has a low limit for certain resources. Try this before starting the postmaster:
ulimit -d 65536 limit datasize 64m
Depending on your shell, only one of these may succeed, but it will set your process data segment limit much higher and perhaps allow the query to complete. This command applies to the current process, and all subprocesses created after the command is run. If you are having a problem with the SQL client because the backend is returning too much data, try it before starting the client.
From psql, type select version();
You need to put BEGIN WORK and COMMIT around any use of a large object handle, that is, surrounding lo_open ... lo_close.
Current PostgreSQL enforces the rule by closing large object handles at transaction commit, which will be instantly upon completion of the lo_open command if you are not inside a transaction. So the first attempt to do anything with the handle will draw invalid large obj descriptor. So code that used to work (at least most of the time) will now generate that error message if you fail to use a transaction.
If you are using a client interface like ODBC you may need to set auto-commit off.
This way always works:
CREATE TABLE test (x int, modtime timestamp default now() );
In releases 7.0 and later, you may use:
create table test (x int, modtime timestamp default 'now');
IN so slow?Currently, we join subqueries to outer queries by sequential scanning the result of the subquery for each row of the outer query. A workaround is to replace IN with EXISTS. For example, change:
SELECT *
FROM tab
WHERE col1 IN (SELECT col2 FROM TAB2)
to:
SELECT *
FROM tab
WHERE EXISTS (SELECT col2 FROM TAB2 WHERE col1 = col2)
We hope to fix this limitation in a future release.
El problema puede venir por varias cosas. Pruebe su función de usuario en un programa independiente.
Está liberando con pfree una memoria que no ha sido asignada con palloc. Tenga cuidado de no mezclar malloc/free y palloc/pfree.
Envíe sus extensiones a la lista de correo pgsql-hackers, y puede que sean incluidas en el subdirectorio contrib/.
Esto requiere dominio tan extremo que los autores no lo han intentado nunca, aunque en principio puede hacerse.
Makefiles no tiene las dependencias adecuadas para los ficheros incluidos. Tiene que hacer un make clean y después otro make