Дата последнего обновления: Вторник 18 Февраля 12:23:04 EDT 2002
Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) ([email protected])
Перевел на русский: Виктор Вислобоков ([email protected])
Самую свежую английскую версию документа можно найти на http://www.PostgreSQL.org/docs/faqs/FAQ.html.
Ответы на вопросы специфичные для конкретных платформ можно найти на http://www.PostgreSQL.org/docs/index.html.
IN
так медленно работаеют?PostgreSQL произносится Post-Gres-Q-L (Пост-Грес-Кью-Эл).
PostgreSQL - это расширение СУБД POSTGRES, исследовательский прототип нового поколения СУБД. PostgreSQL одновременно сохраняет мощную модель данных и общирное количество типов POSTGRES, и замещает язык запросов PostQuel на расширенное подмножество SQL. PostgreSQL - это свободное и полностью открытое программное обеспечение.
Разработку PostgreSQL выполняет команда разработчиков, все участники которой подписаны на список рассылки разработчиков. В настоящее время, их координатором является Марк Форнай (Marc G. Fournier) ([email protected]). (См. секцию 1.6 о том, как подключиться к разработке). Эта команда теперь отвечает за всю разработку PostgreSQL.
Авторами PostgreSQL 1.01 являются Эндрю Ю (Andrew Yu) и Джоли Чен (Jolly Chen). Многие другие внесли свой вклад в перенос на другие платформы, тестирование, отладку и расширение этого кода. Первоначальный код Postgres, из которого появился PostgreSQL, был итогом усилий многих академических студентов, неакадемических студентов и множества разных программистов, работавших под руководством профессора Майкла Стоунбрейкера (Michael Stonebraker) в Калифорнийском университете, Беркли.
Первоначальное имя, данное в Беркли, было Postgres. Когда в 1995 году была добавлена функциональность SQL, это имя было изменено на Postgres95. Но и это имя было изменено в конце 1996 на PostgreSQL.
PostgreSQL попадает под действие следующего COPYRIGHT:
Система Управления Базами Данных PostgreSQL
Portion copyright (c) 1996-2002, PostgreSQL Global Development Group Portions Copyright (c) 1994-6 Regents of the University of California
Предоставляются права на использование, копирование, изменение и распространение данного программного обеспечения и его документации для любых целей, бесплатно и без подписания какого-либо соглашения, при условии что для каждой копии будут предоставлены данное выше замечание об авторских правах, текущий параграф и два следующих параграфа.
КАЛИФОРНИЙСКИЙ УНИВЕРСИТЕТ НЕ НЕСЕТ НИКАКОЙ ОТВЕТСТВЕННОСТИ ЗА ЛЮБЫЕ ПОВРЕЖДЕНИЯ, ВКЛЮЧАЯ ПОТЕРЮ ДОХОДА, НАНЕСЕННЫЕ ПРЯМЫМ ИЛИ НЕПРЯМЫМ, СПЕЦИАЛЬНЫМ ИЛИ СЛУЧАЙНЫМ ИСПОЛЬЗОВАНИЕМ ДАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЛИ ЕГО ДОКУМЕНТАЦИИ, ДАЖЕ ЕСЛИ КАЛИФОРНИЙСКИЙ УНИВЕРСИТЕТ БЫЛ ИЗВЕЩЕН О ВОЗМОЖНОСТИ ТАКИХ ПОВРЕЖДЕНИЙ.
КАЛИФОРНИЙСКИЙ УНИВЕРСИТЕТ СПЕЦИАЛЬНО ОТКАЗЫВАЗЫВАЕТСЯ ПРЕДОСТАВЛЯТЬ ЛЮБЫЕ ГАРАНТИИ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ТОЛЬКО ЭТИМИ ГАРАНТИЯМИ: НЕЯВНЫЕ ГАРАНТИИ ПРИГОДНОСТИ ТОВАРА ИЛИ ПРИГОДНОСТИ ДЛЯ ОТДЕЛЬНОЙ ЦЕЛИ. ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ НА ОСНОВЕ ПРИЦИПА "КАК ЕСТЬ" И КАЛИФОРНИЙСКИЙ УНИВЕРСИТЕТ НЕ ОБЯЗАН ПРЕДОСТАВЛЯТЬ СОПРОВОЖДЕНИЕ, ПОДДЕРЖКУ, ОБНОВЛЕНИЯ, РАСШИРЕНИЯ ИЛИ ИЗМЕНЕНИЯ.
Вышеизложенное является BSD лицензией, классической лицензией программного обеспечения с открытым кодом. Эта лицензия не накладывает ограничений на использование исходного кода. Нам нравится эта лицензия и мы не собираемся её менять.
Обычно, PostgreSQL может работать на любой современной платформе совместимой с Unix. В инструкции по установке, вы найдете список тех платформ, на которых были проведены тестовые запуски PostgreSQL к моменту выхода данной версии.
Клиент
Для запуска на платформах MS Windows возможна компиляция C библиотеки libpq, psql, других интерфесов и клиентских приложений. В этом случае, клиент запускается на MS Windows и связывается по TCP/IP с сервером, запущенным на одной из поддерживаемых Unix платформ. В дистрибутив включается файл win32.mak для того, чтобы можно было провести сборку библиотеки libpq и psql для Win32. PostgreSQL также работает через ODBC.
Сервер
Сервер БД может быть запущен на Windows NT и Win2k, используя библиотеку Cygwin, разработанную для переноса программного обеспечения Unix в NT. Смотрите pgsql/doc/FAQ_MSWIN в дистрибутиве или MS Windows FAQ на http://www.PostgreSQL.org/docs/faqs/faq-mswin.html.
PostgreSQL, спортированный специально для MS Win NT/2000/XP в настоящий момент начал работать.
Например, воспользовавшись анонимным доступом на ftp сайт PostgreSQL ftp://ftp.PostgreSQL.org/pub. Список зеркал вы найдете на нашем основном сайте.
Основной список рассылки: [email protected]. В нем можно обсуждать любые темы, касающиеся PostgreSQL. Чтобы подписаться, отправьте письмо по электронной почте, в котором в теле письма (не в теме) напишите следующие строки:
subscribe end
на адрес [email protected].
Существует дайжест список. Чтобы подписаться на него, отправьте письмо по электронной почте на адрес: [email protected] и в теле письма напишите строчки строчки:
subscribe endДайжесты отправляются подписчикам, когда в основном списке рассылки накопится около 30 килобайт сообщений.
Доступен и список рассылки сообщений об ошибках. Чтобы подписаться на этот список, отправьте по электронной почте письмо на адрес [email protected] и в теле письма напишите строчки строчки:
subscribe endТакже имеется список рассылки с дискуссиями разработчиков. Чтобы подписаться на этот список, отправьте по электронной почте письмо на адрес [email protected] и в теле письма напишите строчки строчки:
subscribe end
Дополнительные списки рассылки и инфомацию о PostgreSQL можно найти на домашней страничке PostgreSQL по адресу:
http://www.PostgreSQL.org
Еще существует IRC канал на EFNet, с названием
#PostgreSQL. Я использую для подключения к этому каналу команду Unix
irc -c '#PostgreSQL' "$USER" irc.phoenix.net.
Список коммерческой поддержки компаний доступен на http://www.ca.PostgreSQL.org/users-lounge/commercial-support.html.
Последний выпуск PostgreSQL - это версия 7.3.2.
Мы планируем выпускать новые версии каждые четыре месяца.
В дистрибутив включаются различные руководства, страницы электронного руководства man и некоторые маленькие тестовые примеры. Смотрите в каталог /doc. Вы также можете просматривать документацию в Интернет по адресу http://www.ca.PostgreSQL.org/users-lounge/docs/.
Существует две книги по PostgreSQL доступные по адресам http://www.PostgreSQL.org/docs/awbook.html и http://www.commandprompt.com/ppbook/. Список книг по PostgreSQL, которые можно купить доступен по адресу http://www.ca.PostgreSQL.org/books/. Кроме того, по адресу http://techdocs.PostgreSQL.org/ вы можете найти коллекцию технических статей посвященных PostgreSQL.
psql имеет несколько прекрасных команд \d для отображения информации по типам, операторам, функциям, агрегатам и т.д.
Наш сайт содержит еще больше информации.
PostgreSQL поддерживает расширенный подкласс SQL-92. Смотрите наш список TODO на предмет известных ошибок, отсутствующих особенностях и будущих планов.
Книга по PostgreSQL на http://www.PostgreSQL.org/docs/awbook.html научит SQL. Существует другая книга по PostgreSQL на http://www.commandprompt.com/ppbook. Есть прекрасный учебник на http://www.intermedia.net/support/sql/sqltut.shtm, на http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, и на http://sqlcourse.com.
Еще один учебник - это книга "Teach Yourself SQL in 21 Days, Second Edition" (Освой самостоятельно SQL за 21 день, Вторая редакция) на http://members.tripod.com/er4ebus/sql/index.htm
Многим из наших пользователей нравится книга The Practical SQL Handbook, Bowman, Judith S., et al., Addison-Wesley. Другим нравится The Complete Reference SQL, Groff et al., McGraw-Hill.
Да, мы легко манипулируем датами после 2000 года и перед 2000 годом.
Для начала, скачайте последнюю версию исходных текстов и прочтите документацию разработчиков PostgreSQL на нашем сайте или в дистрибутиве. Затем, подпишитесь на списки рассылки pgsql-hackers и pgsql-patches. Далее, отправляйте исправления (patches) высокого качества в список pgsql-patches.
Существует ограниченный список людей, который имеют привелегию вносить изменения в CVS архив PostgreSQL. Каждый из этих людей в свое время отправил так много высококачественных исправлений, что их было невозможно оставить без внимания и они были удостоены превилегии вносить изменения, и мы уверены, что те исправления, которые они внесут будут высокого качества.
Пожалуйста посетите страничку PostgreSQL BugTool на http://www.PostgreSQL.org/bugs/bugs.php, на которой предоставлены детальные инструкции о том как отправить сообщение об ошибке.
Также не забудьте посмотреть на ftp://ftp.PostgreSQL.org/pub на предмет более свежих версий PostgreSQL или заплат.
Существует несколько методов сравнения программного обеспечения: возможности, производительность, надежность, поддержка и цена.
PostgreSQL имеет одноранговую инфраструктуру с того самого времени как мы начали разработку в 1996 году. Мы должны благодарить за это Марка Фоная (Marc Fournier), который создал эту инфраструктуру и управляет ей на протяжении этих лет.
Качественная инфраструктура очень важна для проектов с открытым исходным кодом. Она предотвращает расколы, которые могут сильно задержать поступательное движение проекта.
Разумеется, эта инфраструктура не является дешевой. Существует некоторое количество ежемесячных и одноразовых расходов, которые требуют денег. Если вы или ваша компания имеет деньги, которые можно передать в помощь нашим усилиям, пожалуйста посетите страничку https://store.pgsql.com/shopping/ и сделайте свой вклад.
Хотя на страничке говорится о PostgreSQL, Inc, пункт "contributions" предназначен исключительно для поддержки проекта PostgreSQL и не передается какой-либо конкретной компании. Если хотите, то можете это проверить, написав письмо на контактный адрес.
Существует два ODBC драйвера, PsqlODBC и OpenLink ODBC.
Вы можете скачать PsqlODBC с http://gborg.postgresql.org/project/psqlodbc/projdisplay.php.
OpenLink ODBC можно взять на http://www.openlinksw.com. Этот драйвер работает с их стандартным клиентским программным обеспечением, использующим ODBC, и таким образом, ODBC драйверы для PostgreSQL доступны для каждой из поддерживаемых ими платформ (Win, Mac, Unix, VMS).
Возможно они будут продавать свой продукт тем кому нужна коммерческая поддержка, но бесплатная версия всегда будет доступна. Пожалуйста, направляйте вопросы на адрес [email protected].
Прекрасное введение во взаимодействие баз данных и Web можно найти на: http://www.webreview.com
Для интеграции с Web, одним из превосходных инструментов является PHP. Домашняя станичка http://www.php.net.
Для комплексных решений, многие пользуются Perl интерфейсом и CGI.pm или mod_perl.
Да, существует несколько графических интерфейсов для PostgreSQL. Это PgAccess (http://www.pgaccess.org, PgAdmin II (http://www.pgadmin.org, Win32-only), RHDB Admin ( http://sources.redhat.com/rhdb/) и Rekall ( http://www.thekompany.com/products/rekall/, коммерческий). Также есть PHPPgAdmin ( http://phppgadmin.sourceforge.net/) - интерфейс к PostgreSQL, основанный на Web.
Какие-либо интерфейсы для PostgreSQL существуют для большинства популярных языков программирования. Посмотрите список модулей расширения для тех языков программирования, которыми вы пользуетесь.
Следующие интерфейсы включаются в дистрибутив PostgreSQL:
Дополнительные интерфейсы доступны по адресу http://gborg.PostgreSQL.org в секции Drivers/Interfaces.
Задайте опцию --prefix когда запускаете configure.
Это может быть вызвано разными проблемами, но первое, что нужно сделать - это убедиться в том, что в вашем ядре установлено расширение System V. PostgreSQL требует, чтобы ядро поддерживало разделяемую память и семафоры.
Либо у вас в ядре неправильные настройки разделяемой памяти, либо вашему ядру нужно большее количество доступной разделяемой памяти. Те конкретные действия, которые вам нужно произвести зависят от архитектуры вашей машины и от того как много буферов и backend процессов вы настроили для postmaster. Для большинства систем, с количеством буферов и процессов по умолчанию, необходимый минимум - это около 1 мегабайта. Подробности о разделяемой памяти и семафорах смотрите в Руководстве администратора PostgreSQL.
Если это сообщение IpcSemaphoreCreate: semget failed (No space left on device) то настройки вашего ядра таковы, что ему не хватает семафоров. Postgres требует один семафор на потенциальный backend процесс. Временным решением является запуск postmaster с настройками на мешьшее количество backend процессов. Используйте -N с значением меньшим чем 32, которое принято по умолчанию. Более правильное решение - это увеличить значения SEMMNS и SEMMNI в настрйках ядра.
Неисправные семафоры также могут привести к падению СУБД во время доступа к базе данных.
Если вы получили какое-либо другое сообщение об ошибке, то вполне возможно, что в вашем ядре вообще не настроена поддержка семафоров. Смотрите подробности о разделяемой памяти и семафорах в Руководстве Администратора PostgreSQL.
По умолчанию, PostgreSQL разрешает только соединения на локальной машине через сокеты домена Unix. Другие машины не смогут подключиться к базе пока для postmaster не будет задан флаг -i и пока не будет разрешена host-авторизация в файле $PGDATA/pg_hba.conf. Эти действия делают возможными TCP/IP соединения.
Несомненно, индексы могут увеличить скорость выполнения запросов. Команда EXPLAIN позволяет вам посмотреть как PostgreSQL интерпретирует ваш запрос и какие индексы используются.
Если вы выполняете много операторов INSERT, рассмотрите возможность выполнять их в большой пачке, используя команду COPY. Это значительно быстрее, чем отдельные INSERT. Во-вторых, операторы вне блока транзакции BEGIN WORK/COMMIT сами выполняют транзакцию. Подумайте над выполнением нескольких операторов в одном блоке транзакции. Это уменьшит количество транзакций. Также, задумайтесь над удалением и пересозданием индексов, когда вы выполняете большие изменения данных.
Существует несколько опций настройки. Вы можете запретить fsync() при старте postmaster с опцией -o -F. Это предотвратит вызовы fsync(), которые приводят к сбросу данных на диск после каждой транзакции.
Вы можете также использовать для postmaster опцию -B для увеличения количества буферов разделяемой памяти, которая используется backend процессами. Если вы сделаете значение этого параметра слишком большим, то postmaster может не запустится потому что вы исчерпаете ограничение ядра на объем разделяемой памяти. Каждый буфер имеет размер в 8 килобайт и по умолчанию выделяется 64 буфера.
Вы можете также использовать backend опцию -S для увеличения максимального количества памяти, которое используется backend процессом для временных сортировок. Значение для опции -S задается в килобайтах и по умолчанию равно 512 (т.е. 512K).
Вы также можете использовать команду CLUSTER для группировки данных в таблицах на совпадающий индекс. Подробности смотрите на странице руководства по команде CLUSTER.
PostgreSQL имеет несколько возможностей, позволяющие получить информацию о состоянии, которая может быть использована в отладочных целях.
Во-первых, при запуске configure с опцией --enable-cassert, многие вызовы assert() позволяют отслеживать работу backend процесса и остановку программы при возникновении каких-либо неожиданностей.
И postmaster, и postgres имеют несколько отладочных опций. Во-первых, при запуске postmaster, убедитесь, что стандартный вывод и вывод ошибок осуществляются в файл журнала:
cd /usr/local/pgsql ./bin/postmaster >server.log 2>&1 &
Это приведет к появлению файла server.log в главном каталоге PostgreSQL. Этот файл содержит полезную информацию о проблемах или ошибках, возникших на сервере. Postmaster имеет опцию -d, которая позволяет получать при протоколировании более детальную инфрмацию. Для опции -d указывается число, которое задает уровень отладки. Будьте осторожны, так как высокий уровень отладки приводит к генерации файлов журнала большого размера.
Если postmaster не запущен, вы можете запустить postgres backend из командной строки и ввести ваш оператор SQL напрямую. Это рекомендуется только для целей отладки. Заметим, что в этом режиме, запрос завершается символом новой строки, а не точкой с запятой. Если вы производили компиляцию с отладочными символоами, вы можете использовать любой отладчик, чтобы посмотреть, что случилось. Поскольку backend запускается не из postmaster, он не запускается в идентичном окружении и значит проблемы итераций блокировок/backend не могут быть воспроизведены.
Если postmaster запущен, запустите psql в одном окне, затем найдите PID процесса postgres, используемый psql. Используйте отдадчик для подключения к postgres PID. Вы можете установить точки прерывания в отладчике и запустить запрос из psql. Если вы производите отладку запуска postgres, вы можете установить PGOPTIONS="-W n", и затем запустить psql. Эта опция приводит к задержке процесса запуска на n секунд, в течение которых вы можете подключить к процессу отладчик, установить любые точки прерывания и продолжить запуск.
Программа postgres имеет опции -s, -A, и -t которые могут быть очень полезными для отладки и измерения производительности.
Вы также можете скомпилировать PostgreSQL с профилированием для того, чтобы увидеть какие функции сколько времени выполняются. Файлы профилирования backend'а находятся в каталоге pgsql/data/base/dbname. Файл профилирования клиента будет помещен в текущий каталог клиента. В Linux для выполнения профилирования требуется компиляции с -DLINUX_PROFILE.
Вам нужно увеличить ограничение на количество конкуретных backend процессов при запуске postmaster.
По умолчанию установлен лимит на 32 процесса. Вы можете увеличить этот лимит перезапустив postmaster с нужным значением процессов, которое указывается в опции -N или изменив файл postgresql.conf.
Заметим, что если вы зададите в опции -N значение больше 32, то вы также должны увеличить значение в опции -B которое по умолчанию установлено в 64; Значение опции -B должно быть по крайней мере вдвое больше значения опции -N, и возможно ещё больше для лучшей производительности. Для большего количества backend процессов, вам также неплохо было бы увеличить некоторые параметры ядра Unix. Это такие параметры, как максимальное количество блоков разделяемой памяти, SHMMAX; максимальное количество семафоров, SEMMNS и SEMMNI; максимальное количество процессов, NPROC; максимальное количество процессов на пользователя, MAXUPRC; и максимальное количество открытых файлов, NFILE и NINODE. Причина создания ограничения на количество backend процессов как раз и состоит в том, чтобы вашей системе хватило ресурсов.
Данный каталог содержит временные файлы, генерируемые обработчиком запроса. Например, если для выполнения ORDER BY нужна сортировка и эта сортировка требует памяти больше, чем допускает параметр -S у backend'а, то для хранения дополнительных данных создаются временные файлы.
Эти временные файлы должны удаляться автоматически, но этого может не произойти, если backend рухнул во время сортировки. Останов и запуск серверного процесса обеспечит их удаление из каталога.
Разработчики PostgreSQL делают только небольшие изменения между подвыпусками. Таким образом обновление с версии 7.2 до 7.2.1 не требует выполнения dump и restore. Однако при выходе очередного выпуска (т.е. при обновлении например, с 7.2 на 7.3) часто меняется внутренний формат системных таблиц и файлов данных. Эти изменения часто носят комплексный характер, так что нет возможности обеспечить обратную совместимость файлов данных. Выполение dump позволяет получить данные в общем формате, который затем может быть загружен при использовании нового внутреннего формата.
В тех выпусках, где формат данных на диске не меняется, для проведения обновления может быть использован сценарий pg_upgrade без использования dump/restore. Комментарии к выпуску говорит когда можно использовать pg_upgrade для этого выпуска.
Смотрите описание на страницах руководства посвященным DECLARE.
Смотрите станицу руководства посвященную FETCH или используйте SELECT ... LIMIT....
Даже если вы хотите получить только первые несколько записей, будет выполнен весь запрос. Рассмотрим запрос, который имеет ORDER BY. Если есть какой-либо индекс, который совпадает с ORDER BY, PostgreSQL может выдать только несколько первых запрошенных записей или может выполнять запрос пока не будут выданы желаемые записи.
Вы можете посмотреть исходный код psql в файле pgsql/src/bin/psql/describe.c. Он содержит команды SQL которые генерируются при вводе в psql команд, начинающихся с обратной косой черты. Вы также моежете запустить psql с опцией -E так, чтобы эта программа выдавала запросы, которые она использует для выполнения заданных вами команд.
Эта функциональность была добавлена в выпуск 7.3 с оператором ALTER TABLE DROP COLUMN. В ранних версиях, можно сделать так:
BEGIN; LOCK TABLE old_table; SELECT ... -- выборка всех колонок за исключением той, которую хотите удалить INTO TABLE new_table FROM old_table; DROP TABLE old_table; ALTER TABLE new_table RENAME TO old_table; COMMIT;
Существуют следующие ограничения:
Максимальный размер базы? неограничен (существуют базы на 1 TB) Максимальный размер таблицы? 16 TB Максимальный размер записи? 1.6 TB Максимальный размер поля? 1 GB Максимальное количество записей в таблице? неограничено Максимальное количество колонок в таблице? 250-1600 в зависимости от типа Максимальное количество индексов в таблице? неограниченоРазумеется, понятие "неограничено" на самом деле ограничивается доступным дисковым пространиством и размерами памяти/своппинга. Когда значения перечисленные выше неоправдано большие, может пострадать производительность.
Максимальный размер таблицы в 16 TB не требует чтобы операционная система поддерживала файлы больших размеров. Большие таблицы хранятся как множество файлов размером в 1 GB, так что ограничения, которые накладывает файловая система не важны.
Максимальный размер таблицы и максимальное количество колонок могут быть увеличены, если размер блока по умолчанию будет увеличен до 32k.
СУБД PostgreSQL может потребоваться дискового пространства до 5 раз больше для сохранения данных из простого текстового файла.
В качестве примера, рассмотрим файл в 100,000 строк в каждой, из которых целое число и текстовое описание. При этом длина текста, в среднем, составляет 20 байт. Размер простого файла составит 2.8 MB. Размер базы PostgreSQL, содержащей эти же данные составит приблизительно 6.4 MB из которых:
36 байт: на каждый заголовок записи (приблизительно) + 24 байта: одно поле с целочисленным типом и одно текстовое поле + 4 байта: указатель на странице для всей записи ---------------------------------------- 64 байт на запись Размер страницы данных в PostgreSQL составляет 8192 байт (8 KB), так что: 8192 байт на страницу ------------------- = 128 записей на страницу БД (с округлением) 64 байт на запись 100000 строк данных -------------------- = 782 страницы в БД 128 записей на страницу 782 страницы БД * 8192 байт на страницу = 6,406,144 байт (6.4 MB)
Индексы не требуют так много, но поскольку они создаются для большого количества данных, они также могут быть велики.
Значения NULL сохраняются в битах и поэтому они занимают очень мало места.
psql имеет несколько команд, начинающихся с обратной косой черты, для того чтобы просматривать такую информацию. Используйте \? для того, чтобы увидеть эти команды. Также существуют системные таблицы, имя которых начинается на pg_ и в которых также содержится эта информация. Ещё, psql -l покажет список всех баз данных.
Также смотрите файл pgsql/src/tutorial/syscat.source. В нем представлены многие операторы SELECT которые нужны для получения информации из системных таблиц базы данных.
Индексы не используются для каждого запроса автоматически. Они используются только если таблица больше минимального размера и запрос выбирает только маленький процент записей в таблице. Так устроено, потому что доступ к диску с применением рандомизации при сканировании индексов может быть медленнее, чем простое чтение таблицы или ее последовательное сканирование.
Чтобы определить необходимость использования индекса для какой-либо таблицы, PostgreSQL должен иметь статистику по этой таблице. Эта статистика собирается при использовании VACUUM ANALYZE или просто ANALYZE. Используя статистику, оптимизатор узнает о том как много записей в таблице и если он должен использовать индексы, то он может принимать лучшие решения. Статистика также влияет на определение оптимального порядка связывания и метода связывания. Сбор статистики должен периодически выполнятся при изменении содержимого таблицы.
Обычно индексы не используются для ORDER BY или для выполнения связываний. Последовательный перебор следующий за явной сортировкой обычно быстрее, чем поиск по индексам в большой таблице. Однако, ORDER BY часто комбинируется с LIMIT и в этом случае индекс будет использоваться, поскольку при выполнении будет возвращаться небольшая часть таблицы. Фактически MAX() и MIN() не используют индексы, но индекс используется при построении запросов с ORDER BY и LIMIT:
SELECT col FROM tab ORDER BY col [ DESC ] LIMIT 1;
Если вам кажется, что оптимизатор некорретно выбирает последовательный
перебор, используйте SET enable_seqscan TO 'off'
и
запустите тесты, чтобы увидеть, не стало-ли сканирование индексов быстрее.
Когда используются операции с шаблонами, например LIKE или ~, индексы могут быть использованы в следующих случаях:
Смотрите страницу руководства посвященную EXPLAIN.
R-tree индекс используется для индексирования пространственных данных. Индекс хэша не может управлять поисками диапазона. B-tree индекс управляет только поисками диапазона в одном измерении. R-tree индекс может управлять многоразмерными данными. Например, если R-tree индекс может быть встроен в атрибут типа point, то система может более эффективно ответить на запрос типа "выбрать все точки внутри заданного четырехугольника."
Канонический источник, описывающий первоначальное создание R-tree это:
Guttman, A. "R-trees: A Dynamic Index Structure for Spatial Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
Вы можете найти этот документ в книге Stonebraker'а "Readings in Database Systems".
Встроеннные R-tree могут управлять полигонами и боксами. В теории, R-tree могут быть расширены для управления большим количеством измерений. На практике, расширение R-tree требует некоторых усилий и у нас, в данный момент, нет какой-либо документации о том, как это сделать.
Модуль GEQO производит быструю оптимизацию запроса, когда происходит связывание многих таблиц через Genetic Algorithm (GA). Это позволяет управлять большими запросами на связывание через неистощающий поиск.
Оператор ~ производит поиск регулярного выражения, а оператор ~* производит независимый от регистра букв поиск регулярного выражения. Независимый от регистра вариант LIKE называется ILIKE.
Независимое от регистра сравнение обычно выражается так:
SELECT * FROM tab WHERE lower(col) = 'abc';Эта конструкция не будет использовать стандартный индекс. Однако, если вы создадите функциональный индекс, он будет использован:
CREATE INDEX tabindex ON tab (lower(col));
Вы просто сравниваете значение с IS NULL и IS NOT NULL.
Тип Внутреннее имя Замечания -------------------------------------------------- VARCHAR(n) varchar размер задает максимальную длину, нет заполнения CHAR(n) bpchar заполняется пустотой до фиксированной длины TEXT text нет задаваемого верхнего ограничения или длины BYTEA bytea массив байт переменной длины (можно использовать null-байт без опаски) "char" char один символ
Внутреннее имя вы можете увидеть, когда смотрите системные каталоги и в некоторых сообщениях об ошибках.
Первые четыре типа являются "varlena" типами (т.е., первые четыре байта на диске являются длинной, за которой следуют данные). Таким образом, фактически используемое пространство больше, чем обозначенный размер. Однако, эти типы данных также поддаются сжатию или могут быть сохранены не в строком виде через TOAST, так что занимаемое дисковое пространство может также быть и меньше, чем ожидалось.
VARCHAR(n) - это лучшее решение, когда нужно хранить строки переменной длины, не превышающие определенного размера. TEXT - это лучшее решение для строк неограниченной длины, с максимально допустимой длиной в 1 гигабайт.CHAR(n) - это лучшее решение для хранения строк, которые обычно имеют одинаковую длину. CHAR(n) заполняется пустотой до заданной длины, в то время как VARCHAR(n) хранит только символы, из которых состоит строка. BYTEA используется для хранения бинарных данных, значения которых могут включать NULL байты. Все типы описанные здесь, имеют сходные характеристики производительности.
PostgreSQL поддерживает тип данных SERIAL. Он автоматически создает последовательность и индекс для колонки. Например:
CREATE TABLE person ( id SERIAL, name TEXT );автоматически транслируется в:
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 );Смотрите подробности о последовательностях на странице руководства посвященной create_sequence. Вы также можете использовать каждое поле OID в записи как уникальное значение. Однако, если вам нужен дамп и перезагрузка базы данных, вам необходимо использовать команду pg_dump с опцией -o или опцию COPY WITH OIDS для сохранения значений поля OID.
Один из способов состоит в получении следующего значения SERIAL из объекта sequence с помощью функции nextval() перед вставкой и затем вставлять это значение явно. Используйте таблицу-пример в 4.15.1, пример в псевдоязыке покажет как это делается:
new_id = execute("SELECT nextval('person_id_seq')"); execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");Затем вы должны также сохранить новое значение в переменной
new_id
для его использования в других запросах (например
таких как внешний ключ для таблицы person
). Заметим,
что имя автоматически созданного объекта SEQUENCE
будет <table>_<serialcolumn>_seq,
где table и serialcolumn являются соответственно
именами вашей таблицы и вашей колонки SERIAL.
В качестве альтернативы, вы можете получить назначенное значение SERIAL с помощью функции currval() после проведения обычной операции вставки, например
execute("INSERT INTO person (name) VALUES ('Blaise Pascal')"); new_id = execute("SELECT currval('person_id_seq')");И наконец, вы можете использовать значение OID, возращаемое из опертора INSERT чтобы увидеть значение по умолчанию, что предположительно является наименее переносимым на другие платформы решением. В Perl, используя DBI с модулеи Edmund Mergl'я DBD::Pg, значение oid становится доступным через $sth->{pg_oid_status} после $sth->execute().
Нет. currval() возвращает текущее значение, назначенное вашем backend'ом, а не другими пользователями.
Для реализации конкуретности, значения последовательностей, при необходимости выдаются во время запуска транзакций и не блокируются до полного выполнения транзакций. Это может вызывать разрывы в нумерации при отмене транзакций.
Поля OID служат уникальными идетификаторами записей в PostgreSQL. Каждая запись, которая создаётся в PostgreSQL получает уникальный OID. Все значения OID генерируемые во время initdb имеют значения меньше 16384 (из include/access/transam.h). Все созданные пользователем OID имеют бОльшие значение. По умолчанию, все эти OID являются уникальными не только внутри какой-либо таблицы или базы данных, но и внутри всей СУБД PostgreSQL.
PostgreSQL использует OID в своих внутренних системных таблицах для связи записей и таблиц. Значения OID могут быть использованы для идентификации заданных пользователем записей, а также использоваться при связываниях. Рекомендуется использовать тип колонки OID для хранения значений OID Вы можете создать индекс на поле OID для более быстрого доступа.
Значения OID назначаются для всех новых записей из центральной области, которые используются всеми всеми базами данных. Если вы хотите изменить OID на какое-либо другое значение или если вы хотите создать копию таблицы с такимиже OID, то это можно сделать так:
CREATE TABLE new_table(old_oid oid, mycol int); SELECT old_oid, mycol INTO new FROM old; COPY new TO '/tmp/pgtable'; DELETE FROM new; COPY new WITH OIDS FROM '/tmp/pgtable';
OID хранится как 4-х байтное целое и не может превышать значение в 4 миллиарда. Однако, еще никто не сообщил о том, что такое произошло, но мы планируем до того как это случиться избавится от этого ограничения.
TID используется для идентификации специальных физических записей с блочными и offset значениями. TID изменяется после того как записи были изменены или перегружены.
TID используется индексными записями в качестве указателя на физические записи.
Некоторый исходный код и старая документация используют общеупотребительные термины. Вот некоторые из них:
Список общих терминов по базам данных можно найти на http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html
Предположительно у вас закончилась виртуальная память или что ваше ядро имеет маленький лимит на определенные ресурсы. Попытайтесь перед запуском postmaster выполнить следующие команды:
ulimit -d 262144 limit datasize 256mВ зависимости от командного интерпретатора shell, только одна из данных команд выполнится успешно, но она позволит вам установить больший сегмент данных процесса и возможно решит проблему. Эта команда изменяет параметры текущего процесса и всех его потомков, созданных после её запуска. Если у вас возникла проблема с SQL клиентом, потому что backend возвращает слишком большой объем данных, попытайтесь выполнить эту команду перед запуском клиента.
Из psql, наберите SELECT version();
Вам нужно при использовании большого объекта поместить в начале
BEGIN WORK
и в конце COMMIT
, а внутри
получившегося блока lo_open
... lo_close.
В настоящий момент PostgreSQL требует, чтобы при закрытии большого объекта происходило выполнение транзакции. Таким образом, первая же попытка сделать что-либо с большим объектом, не соблюдая данного правила приведет к сообщению invalid large obj descriptor, так как код выполняющий работу над большим объектом (по крайней мере в настоящий момент) будет генерировать сообщение об ошибке если вы не используете транзакцию.
Если вы используете такой интерфейс клиента как ODBC,
вам возможно понадобится установить auto-commit off.
Используйте CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
IN
так медленно работаеют?В настоящий момент, мы связываем позапросы для внешних запросов
через последовательный перебор результата подзапроса для каждой
записи внешнего запроса. Если подзапрос возвращает только несколько
записей и внешний запрос возвращает много записей,
IN
работает наиболее быстро. Чтобы
увеличить скорость в других запросах, замените IN
на
EXISTS
:
SELECT * FROM tab WHERE col IN (SELECT subcol FROM subtab);на:
SELECT * FROM tab WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col);Чтобы такая конструкция работала быстро, колонка
subcol
должна быть проиндексирована. Эта проблема производительности будет
устранена в версии 7.4.
PostgreSQL поддерживает внешнее связывание, используя стандартный синтаксис SQL. Вот два примера:
SELECT * FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);или
SELECT * FROM t1 LEFT OUTER JOIN t2 USING (col);
Это идентичные запросы связывания t1.col и t2.col, также возвращают любые несвязанные записи в t1 (которые не совпадают с t2). RIGHT связывание должно добавить несвязанные записи t2. FULL связывание должно возвратить совпавшие записи плюс все несвязанные записи из t1 и t2. Слово OUTER является необязательным и назначается в LEFT, RIGHT и FULL связываниях. Обычные связывания называются INNER связывания.
В предыдущих версиях, внешние связывания могли быть эмулированы
используя UNION и NOT IN. Например,
когда происходит связывание tab1 и tab2, следующий
запрос выполняет внешнее связывание двух таблиц:
SELECT tab1.col1, tab2.col2 FROM tab1, tab2 WHERE tab1.col1 = tab2.col1 UNION ALL SELECT tab1.col1, NULL FROM tab1 WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2) ORDER BY col1
Не существует способа создать запрос к базам данных отличным от текущей. Поскольку PostgreSQL загружает системные каталоги специфичные для базы данных, непонятно даже, как должен себя вести такой межбазовый запрос.
contrib/dblink позволяет запросы между базами, используя вызовы функций. Разумеется, клиент может одновременно устанавливать соедиенения с различными базами данных и таких образом объединять информацию из них.
Вы можете возвращать из функций PL/pgSQL списки результатов, используя refcursors. Смотрите http://www.PostgreSQL.org/idocs/index.php?plpgsql-cursors.html, секцию 23.7.3.3.
PL/PgSQL кэширует содержимое функции и один из негативных эффектов этого состоит в том, что если функция PL/PgSQL обращается к временной таблице и эта таблица позднее удаляется и пересоздается, а функция затем вызывается снова, то ее вызов приведет к ошибке, потому что скэшированное содержимое функции содержит указатель на старую временную таблицу. Чтобы решить эту проблему, используйте EXECUTE для доступа к временным таблицам в PL/PgSQL. Использование этого оператора заставит запрос перегенерироваться каждый раз.
Есть несколько опций для репликации типа master/slave. Они допускают использование только master сервера для внесения изменений в базу данных, а slave серверы просто позволяют читать данные из базы. Об этом читайте здесь: http://gborg.PostgreSQL.org/genpage?replication_research. О репликации с несколькими master серверами читайте здесь: http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
Проблема может заключаться в нескольких вещах. Попытайтесь сперва протестировать вашу функцию в отдельной самостоятельной программе.
Отправьте ваши расширения в список рассылки pgsql-hackers и они по возможности будут помещены в подкаталог contrib/.
В версиях PostgreSQL, начиная с 7.3, функции, возвращающие таблицы полностью поддерживаются в C, PL/PgSQL и SQL. Подробности смотрите в Руководстве Программиста. Пример возвращающей таблицу функции, написанной на C, можно найти в contrib/tablefunc.
Файлы Makefile не имеют правильных зависимостей для include файлов. Вы должны выполнить make clean и затем make. Если вы используете GCC вы можете использовать опцию --enable-depend в configure чтобы поручить компилятору автоматически отслеживать зависимости.