Ú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/.
La versión más reciente de este documento en Español puede visualizarse en el sitio web del Proyrcto de tradución de la documentación de postgreSQL, http://users.servicios.retecal.es/rsantos/index.htm o en su replica http://lucas.hispalinux.es/Postgresql-es/rsantos/
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) El sistema parece confundirse con las comas, puntos decimales y los formatos de fechas.
4.2) ¿Cuál es la diferencia exacta entre cursores binarios y cursores normales?
4.3) ¿Cómo seleccionar solamente las primeras filas de una consulta?
4.4) ¿Cómo obtener una lista de tablas u otras cosas que pueda ver con psql?
4.5) ¿Cómo borrar una columna de una tabla?
4.6) ¿Cuál es el tamaño máximo de una fila, tabla o base de datos?
4.7) ¿Cuánto espacio de disco requiere una base de datos para almacenar un fichero normal y corriente?
4.8) ¿Cómo saber qué índices u operaciones están definidos en la base de datos?
4.9) Mis consultas van despacio o no hacen uso de índices. ¿Porqué?
4.10) ¿Cómo ver de qué manera el optimizador de consultas está evaluando mi consulta?
4.11) ¿Qué es un índice R-tree?
4.12) ¿Qué es una optimización genérica de una consulta?
4.13) ¿Cómo hacer búsquedas de expresiones regulares y búsquedas de expresiones regulares sensibles al contexto?
4.14) En una consulta, ¿cómo detectar si un campo es NULL (nulo)?
4.15) ¿Cuál es la diferencia entre los diferentes tipos de caracteres?
4.16.1) ¿Cómo crear un campo serie/autoincremento?
4.16.2) ¿Cómo obtener el valor de una inserción serie (serial insert)?
4.16.3) ¿No provoca el uso de currval() y nextval() una condición de competencia con otros procesos concurrentes del backend?
4.17) ¿Qué es un oid? ¿Qué es un tid?
4.18) ¿Cuál es el significado de algunos términos usados en PostgreSQL?
4.19) ¿Porqué me da este error "FATAL: palloc failure: memory exhausted?"
4.20) ¿Cómo saber qué versión de PostgreSQL estoy usando?
4.21) Las operaciones con objetos grandes me dan el mensaje invalid large obj descriptor. ¿Porqué?
4.22) ¿Cómo creo una columna que tome por defecto la hora actual?
4.23) ¿Porqué son tan lentas mis sub-consultas cuando uso IN?
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:
Compruebe su configuración local. PostgreSQL utiliza la configuración local del usuario que arranca el proceso postmaster. Existen comandos SET de postgres y psql para controlar el formato de fecha. Fije este valor de acuerdo con su entorno habitual.
Vea la página del manual de DECLARE para una descripción.
Vea la página del manual de FETCH o utilice SELECT ... LIMIT....
Puede que se deba evaluar la consulta entera, aun en el caso de que quiera que evalúe unas pocas filas. Considere usar una consulta que tenga ORDER BY. Si hay un índice que concuerda con ORDER BY, PostgreSQL será capaz de evaluar sólo los primeros registros pedidos o se evaluará la totalidad de la consulta hasta que se obtengan las filas requeridas.
Puede leer el código fuente de psql, pgsql/src/bin/psql/psql.c. Contiene comandos SQL que generan la salida en la línea de comando de psql. También puede arrancar psql con la opción -E, de modo que le mostrará las consultas que utiliza para ejecutar los comandos que usted le pasa.
No se soporta ALTER TABLE DROP COLUMN, pero puede hacer eso:
SELECT ... -- seleccione todas las columnas excepto las que quiera borrar INTO TABLE nueva_tabla FROM vieja_tabla; DROP TABLE vieja_tabla; ALTER TABLE nueva_tabla RENAME TO vieja_tabla;
Las filas están limitadas a un tamaño de 8 Kb, pero esto se puede cambiar editando include/config.h y cambiando BLCKSZ. Para usar atributos más grandes que 8 Kb, puede usar el interfaz para objetos grandes.
Las filas no pasan el límite de 8 Kb, por lo que una fila de 5 Kb requiere 8 Kb para almacenarse.
Para tablas y bases de datos no existen límites. Hay muchas bases de datos que tienen decenas de gigabytes y algunas incluso cientos.
Una base de datos Postgres puede requerir alrededor de 6 veces y medio más de disco que lo que necesita para almacenar un fichero normal.
Considere un fichero de 300.000 líneas con dos enteros en cada línea. Un fichero normal ocuparía 2,4 Mb, mientras que una base de datos de PostgreSQL con esos datos se estima que ocuparía unos 14 Mb:
36 bytes: cada cabecera de columna (aproximado)
+ 8 bytes: dos campos con enteros, 4 cada uno
+ 4 bytes: puntero en página a un tuplo
----------------------------------------
48 bytes por fila
La página de datos en PostgreSQL es 8192 bytes (8 KB). Así que:
8192 bytes por página
------------------- = 171 filas por base de datos (redondeo hacia arriba)
48 bytes por fila
300000 filas de datos
-------------------- = 1755 páginas en la base de datos
171 filas por página
1755 página base datos * 8192 bytes por página = 14.376.960 bytes (14 Mb)
Los índices no tienen tanta sobrecarga, pero contienen los datos que están siendo indexados, por lo que también pueden ser grandes.
psql tiene una variedad de comandos con barra invertida para mostrar esta información. Utilice \? para verlos.
Pruebe también pgsql/src/tutorial/syscat.source. Muestra muchos de los SELECTs necesarios para obtener información de las tablas del sistema de base de datos.
PostgreSQL no mantiene automáticamente estadísticas. Cada uno debe hacer explícitamente una llamada a VACUUM para actualizar las estadísticas. Después de que éstas se hayan actualizado, el optimizador conoce cuántas filas hay en la tabla y puede decidir mejor si debería utilizar índices. Tenga en cuenta que el optimizador no usa índices en los casos en que la tabla es pequeña, debido a que una búsqueda secuencial es más rápida.
Utilice VACUUM ANALYZE para estadísticas optimizadas específicas para columnas. VACUUM ANALYZE es importante para consultas complejas de tipo multi-join, de modo que el optimizador puede estimar el número de filas devueltas desde cada tabla y escoger el orden correcto de un "join". El backend no trata estadísticas de columna por sí solo, así que VACUUM ANALYZE debería ejecutarse periódicamente para obtener periódicamente estas estadísticas.
Normalmente no se usan los índices para operaciones de tipo ORDER BY: una búsqueda secuencial seguida de una ordenación explícita es más rápida que una búsqueda por índices de todos los tuplos de una tabla grande porque emplea más accesos a disco.
Cuando utilice operadores comodín como LIKE o ~, los índices sólo pueden ser usados si el comienzo de la búsqueda fijada al comienzo de de la cadena (string). Así que para usar índices, las búsquedas con LIKE no deberían empezar con %, y ~ (expresiones regulares de búsqueda) debería empezar con ^.
Vea en el manual la explicación de EXPLAIN.
Un índice r-tree es usado para indexar datos espaciales. Un índice hash no puede manejar búsquedas por rangos. Un índice B-tree solamente maneja búsquedas por rango de una dimensión. Los R-tree pueden manejar datos multidimensionales. Por ejemplo, si un índice R-tree index puede ser construido sobre un atributos del tipo point, el sistema puede responder más eficientemente a consultas como seleccionar todos los puntos dentro de un rectángulo.
El escrito que describe el diseño original de los R-Tree es:
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.
También puede encontrar esta documentación en "Readings in Database Systems", de Stonebraker
Los R-Trees presentes pueden manejar polígono y cahas. En teoría los R-trees pueden ser ampliados para manejar un mayor número de dimensiones. In la práctica, ampliar los R-trees requiere un poco de trabajo y actualmente no disponemos de documentación sobre cómo hacerlo.
El modulo de PostgreSQL llamado GEQO tiene el propósito de resolver el problema de optimización de las consultas que resultan de unir varias tablas por medio de un Algoritmo Genético (Genetic Algorithm, GA). Permite manejar grandes consultas tipo "join" por medio de búsquedas no exhaustivas.
Para mayor información, consulte la documentación.
El operador ~ realiza coincidencias de expresiones regulares y ~* realiza coincidencias sensibles a mayúsculas y minúsculas en expresiones regulares. No hay ninguna variante de LIKE sensible a mayúsculas/minúsculas, pero puede obtener el efecto de sensibilidad a mayúscula/minúsculas LIKE con esto:
WHERE lower(texto) LIKE lower(patrón)
Utilice IS NULL e IS NOT NULL.
Tipo Nombre interno Notas -------------------------------------------------- "char" char 1 carácter CHAR(#) bpchar relleno con espacios en blanco hasta la longitud especificada VARCHAR(#) varchar longitud máxima, no relleno TEXT text longitud limitada sólo por longitud máxima de fila BYTEA bytea array de bytes de longitud variable
Verá el nombre interno cuando examine los catálogos de sistema o en algunos mensajes de error.
Los cuatro últimos tipos son tipos "varlena" (es decir, los primeros cuatro bytes son la longitud, seguidos de los datos). char(#) asigna el número máximo de bytes sin tener en cuenta cuánntos datos están almacenados en el campo. text, varchar(#), y bytea tienen una longitud variable en el disco y, por esto, hay una penalización en las prestaciones cuando los usa, Esta penalización se da cuando accede a todas las columnas después de acceder a la primera de este tipo.
PostgreSQL soporta tipos de datos SERIAL. Automáticamente crea una secuencia e índice en la columna. Por ejemplo, esto...
CREATE TABLE person ( id SERIAL, name TEXT );
...se traduce automáticamente a esto otro...
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 );
Consulte create_sequence en el manual para tener más información sobre secuencias. También puede usar cada campo oid de las filas como valor único. Sin embargo, si necesita volcar y recargar la base de datos deberá usar la opción pg_dump -o o COPY WITH OIDS para preservar los oid.
Para más detalles vea el capítulo de Bruce Momjian chapter en Numbering Rows.
Quizás la manera más simple es obteniendo el próximo valor de la serie del objeto secuencia con la función nextval() antes de insertar y entonces insertarlo explícitamente. Usando la tabla de ejemplo en 4.16.1, que aperecería así:
$newSerialID = nextval('person_id_seq');
INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
Entonces tendrá también el nuevo valor almacenado en $newSerialID para ser usado en otras consultas (por ejemplo, como una clave foránea en la tabla person). Tenga que el nombre que el nombre del objeto secuencia automáticamente creado será <table>_<serialcolumn>_seq, donde table y serialcolumn son los nombres de la tabla y la columna SERIE respectivamente.
Del mismo modo, podría recuperar el recién asignado valor serie con la función currval() después de que fuera insertado por defecto. Por ejemplo:
INSERT INTO person (name) VALUES ('Blaise Pascal');
$newID = currval('person_id_seq');
Finalmente, puede utilizar el oid devuelto desde la declaración INSERT para encontrar el valor por defecto, aunque esta es la aproximación menos portable. En perl, usando DBI con el módulo de Edmund Mergl DBD::Pg, el valor oid se muestra disponible por medio de $sth->{pg_oid_status} después de $sth->execute().
No. Esto es gestionado por los backends.
Los OID son las respuesta de PostgreSQL a ids de filas únicas. Cada fila que es creada en PostgreSQL obtiene una única oid. Todos los oid generados durante initdb son menos de 16384 (de backend/access/transam.h). Todos los oid creados por el usuario son mayor o igual que este. Por defecto, todos estos oid son únicos, no sólo dentro de tablas o bases de datos, sino también a lo largo de la instalación de PostgreSQL.
PostgreSQL usa oids en sus tablas internas de sistema para enlazar filas entre tabalas. Estos oids pueden ser usados para identificar filas de un usuario específico y usados también en joins. Se recomienda que use oid tipo columna para almacenar los valores oid. Vea la sección de manual sql(l) para estudiar las otras columnas internas. Puede crear un índice en el campo oid para accesos más rápidos.
Los oids se asignan a cada nueva fila de un área central que es usada por todas las bases de datos. Si quiere cambiar el oid a cualquier otro valor o si quiere hacer una copia de una tabla con los oids originales, no hay ninguna razón que se lo impida:
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';
Los tids se usan para identificar filas específicas con bloques y valores de desplazamiento (offset). Los tids cambian después de que se haya modificado o recargado una fila. Son usado por las entradas de índice apuntar a filas físicas.
Parte del código fuente y documentación vieja usa términos que tienen un uso más común. Aquí están algunos:
Es posible que su sistema se haya quedado sin memoria virtual o que el kernel tenga un límite muy bajo para ciertos recursos. Intento probar esto antes de arrancar el postmaster:
ulimit -d 65536 limit datasize 64m
Dependiendo de su shell, solamente uno de ellos puede tener éxito, pero fijará el límite del segmento de datos de su proceso a un valor más alto y quizás permita que la consulta termine. Este comando se aplica al proceso actual y a todos los sub-procesos creados después de que el comando se ejecutara. Si tiene problemas con el cliente SQL porque el backend devuelve demasiados datos, pruébelo antes de arrancar el cliente.
Desde psql, escriba select version();
Debe poner BEGIN WORK y COMMIT para englobar cualquier uso de objetos grandes, esto es, que englobe lo_open ... lo_close.
PostgreSQL impone la regla de cerrar el uso de objetos grandes en transacciones y daría un error en el comando lo_open si no se está dentro de una transacción. De modo que el primer intento de hacer cualquier cosa con él pintará en pantalla invalid large obj descriptor. El código que antes funcionaba generará ahora ese mensaje de error si usted falla al realizar una transacción.
Si está utilizando un interfaz cliente como ODBC, puede ser necesario que especifique auto-commit off.
Esto siempre funciona:
CREATE TABLE test (x int, modtime timestamp default now() );
En las versiones 7.0 y posteriores puede usar:
create table test (x int, modtime timestamp default 'now');
IN?Normalmente unimos sub-consultas con otras externas haciendo una búsqueda secuencial de los resultados de la sub-consulta para cada fila de la consulta externa. Un modo de evitar esto es reemplazar IN con EXISTS. Por ejemplo, cambie:
SELECT *
FROM tab
WHERE col1 IN (SELECT col2 FROM TAB2)
por:
SELECT *
FROM tab
WHERE EXISTS (SELECT col2 FROM TAB2 WHERE col1 = col2)
Esperamos eliminar esta limitación en futuras versiones
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