Вопросы по SQL и другие аспекты работы PostgreSQL

warning: Creating default object from empty value in /var/www/victor/web/pgdocs.ru/data/modules/taxonomy/taxonomy.pages.inc on line 33.
Здесь обсуждаются запросы на SQL в PostgreSQL. Оптимизация запросов, реализация, подходы и т.д.

вопрос по postgre 8.4 и returns table statement

Привет всем!

Вышла тут 8.4 Постгре версия. В ней появился RETURNS TABLE statement

Вопрос, подскажите, знатоки, как реализовать вот такую задачу, используя RETURNS TABLE, а не создание собственного Type (как это сделал я). Мне зачастую приходится делать функции, в которых надо выбрать 1-3 поля из 1 таблицы и все поля из другой...

CREATE OR REPLACE FUNCTION webgame_getquestionsbystepquest(sid bigint, dis integer)
  RETURNS SETOF type_svs AS
$BODY$
DECLARE DATA type_svs%rowtype;
DECLARE status_str varchar;
DECLARE sql varchar;
BEGIN
    status_str:='';

Видимость данных в транзакциях

Изображение s3men

Помогите разобраться с определением "транзакция". Вот пишется что при запросе к БД каждая транзакция видит как бы снимок данных (версию) на момент этого снимка, а не текущее состояние данных. Для данных которые изменяются в транзакции - да, их не видно извне. Но подтверждённые данные становятся видимыми этой транзакции. Таким образом если в транзакции сделать 2 запроса через некоторое время, то они вполне могут вернуть разный результат. И что же делать? Блокировать таблицы что ли?

тот же пример с банковским счетом :
- на счету 100 баксов

Как работает ALTER в Postgresql?

Я перебираюсь с PHP+MySQL на Python+Postgres и у меня есть 2 вопроса.

View. Правила вставки

В продолжение вопроса, поднятого тут (Наследование и уникальные индексы). Если вкратце - от предложенного в postgres наследования пришлось отказаться и делать все через связи таблиц и view.
Мне очень захотелось попробовать скрыть на БД за view всю эту структурную кашу с наследованием. Разобрался с обновлением родительских таблиц, и с удалением. А вот на вставке данных возникла проблема.
Код правила на вставку такой:

CREATE OR REPLACE RULE test_child_insert AS ON INSERT TO test_child DO INSTEAD (

Где можно почитать про create implicit sequence ?

Не могу найти в доках про это.
У меня выскачила такая ошибка , как исправить не пойму.
SQLError ERROR: multiple primary keys for table "uniques" are not allowed
QPSQL: Unable to create query
ERROR ON QUERY 0:alter table uniques add column __id bigserial not null PRIMARY KEY

оптимизация запросов INNER JOIN

Читал что для FireBird очень актуальна для оптимизации правильное расстановка "фильтров". под фильтрами имею ввиду условия используемые в Where , так вот ниже привожу пример запроса который якобы быстрее работает
select s.id, s.name, t.no from school.lessonsweek w inner join school.subjects s
on w.id_sectors=1 and w.id_groups=14 and dayweek=1 and w.id_subjects = s.id

сравнение Character varying[ ] c сравнение Character varying[N]

Интересует сколько реально выделяется байт под поле сравнение Character varying[] и поле с ограниченной длиной сравнение Character varying[N], где N - кол-во символов
Имеется ввиду оба поля пустые еще без данных .

хранимые процедуры и тип входных параметров

Можно ли в виде входного параметра хранимой процедуры использовать переменную типа Record.
форма записи параметров подобных типов для вызова хранимой процедуры из PHP скрипта.

узкие места

День добрый.
Есть определенная проблема.
Сервер: 2х4 ксеона, рэйд 3 зеркала, диски сата
OS: SuSE 10.2 Ent Server
Postgres: "PostgreSQL 8.3.3 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.1" (от 1С 8.1 patch)
Linux'овый 1С 8.1.13 (Конфигурация не стандартная) на этом же сервере

FTS медленнее, чем LIKE

Здравствуйте!
Разбираюсь с полнотекстовым поиском. Столкнулся с такой проблемой:
billing=# select count(*) from a where to_tsvector('russian', body) @@ to_tsquery('пакет');
count
--------
208488
(1 запись)

Время: 31376,000 мс
billing=# select count(*) from a where body like '%пакет%';
count
--------
208488
(1 запись)

Время: 15868,000 мс
Т.е. полнотекстовый поиск в два раза медленнее простого LIKE'а.
Таблица:

Собранный материал

Back to top

(С) Виктор Вислобоков, 2008-2023