День добрый.

Надеюсь, что местные гуру помогут решить данную проблему.

Конфигурация тестовой машины:
PostgreSQL 8.1.4 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special) под WinXP Prof SP2 (NTFS), P4-2600 HT, 512 MB RAM, IDE Maxtor (70 GB).

postgresql.conf
work_mem = 16192
shared_buffers = 4096
sort_mem = 4096
temp_buffers = 1000

Тестируя приложение на локальной базе (пара табличек максимальная всего 250 тыс. записей) обратил внимание на чудовищные с моей точки зрения тормоза по сравнению с MySQL 5.0.24-community-nt.

Примеры:

CREATE TABLE "public"."fares" (
"ID" INTEGER NOT NULL,
"FaRecordLength" VARCHAR(4),
"FaRecordType" VARCHAR(2),
"FaID" VARCHAR(10) NOT NULL,
"FaBlockID" VARCHAR(19) NOT NULL,
"FaAktion" VARCHAR(1),
"FaTkRef" VARCHAR(18),
"FaRlRef" VARCHAR(18),
"FaRtRef" VARCHAR(900),
"FaTariffTitle" VARCHAR(20),
"FaStructDeparture" VARCHAR(60),
"FaStructArrival" VARCHAR(273),
"FaValidPairs" VARCHAR(128),
"FaSeasonCode" VARCHAR(3),
"FaLastReturn" VARCHAR(8),
"FaAdtRt" VARCHAR(1),
"FaChdRt" VARCHAR(1),
"FaInfRt" VARCHAR(1),
"FaAdtOw" VARCHAR(11),
"FaChdOw" VARCHAR(1),
"FaInfOw" VARCHAR(1),
"FaAdtRtNet" VARCHAR(11),
"FaAdtOwNet" VARCHAR(11),
"FaAdtRtTkt" VARCHAR(11),
"FaAdtOwTkt" VARCHAR(11),
"FaChdDiscount" VARCHAR(3),
"FaChdIata" VARCHAR(1),
"FaInfDiscount" VARCHAR(3),
"FaInfIata" VARCHAR(1),
"FaBlackOutDates" VARCHAR(80),
"FaDatePurchase" VARCHAR(8),
"FaLastDatePurchase" VARCHAR(8),
"FaNotesIn" VARCHAR(4),
"FaNotesOut" VARCHAR(1),
"FaBruttoNettoSwitch" VARCHAR(1),
"FaFareSeekCode" VARCHAR(1),
"FaBlackOutDatesOut" VARCHAR(32),
"FaBroker" VARCHAR(29),
"FaAdtRtMinSelling" VARCHAR(6),
"FaAdtOwMinSelling" VARCHAR(6),
"FaCommissionRtAdt" VARCHAR(6),
"FaCommissionOwAdt" VARCHAR(6),
"crc" VARCHAR(32),
CONSTRAINT "fares_pkey" PRIMARY KEY("ID")
) WITHOUT OIDS;

CREATE INDEX "fares_idx" ON "public"."fares"
USING btree ("crc");

1. запрос
select count(*) from
(
select count(*), crc
from fares
group by crc
having count(*) > 1
) test


PG: 55 sec (повтор - 49 sec).
MySQL: 7 sec (повтор - 0.5 sec).

2. select max(LENGTH("FaRtRef")) from fares

PG: 18 sec (повтор 16 sec.)
MySQL: 1 sec (повтор - 0.7 sec).

3. PS. Таблица fares_new копия таблицы fares,
только с количеством записей +~1000

select count(*) from fares_new
where crc not in (
select crc
from fares
where fares.crc = fares_new.crc )

PG: 109 sec (повтор 79 sec.)
MySQL: 4 sec (повтор - 3 sec).

Подскажите, пожалуйста, какие настройки надо подкрутить у PG, чтобы избавиться от тормозов.

Заранее спасибо!

Алексей.

PS. vacuum full analyze делал.

Тормозит, к сожалению, не только count(*):

2.
select max(LENGTH("FaRtRef")) from fares

PG: 18 sec (повтор 16 sec.)
MySQL: 1 sec (повтор - 0.7 sec).

4.
select * from fares_new
where crc not in (
select crc
from fares
where fares.crc = fares_new.crc )
limit 10

PG: 30 sec (повтор 79 sec.)
MySQL: 3 sec (повтор - 2.5 sec).

А разобраться хотелось бы именно с настройкой PG.

Всем спасибо за идеи по параметрам и корректировку запросов! После подкрутки и установки на нормальный сервер (Dual Xeon 2.8, 1GB) все залетало.

К сожалению на 512 MB памяти мне так и не удалось добиться приемлемой производительности PG. Перепробовал кучу вариантов параметров настройки - все мимо - сервер стоит колом, шуршит диском и не использует индексы там, где их использует MySQL:

explain analyze
select count(*) from
(
select count(*), crc
from fares
group by crc
having count(*) > 1
) test


по этому запросу плана выполнения получить не удалось - сервер ушел в стопор и не вернулся :(

select count(*) from fares_new
where crc not in (
select crc
from fares
)

Настройка сервера приаттачена. Если у кого будут идеи или опыт тюнинга PG на 512 MB памяти - welcome!

Sad SpiritНу, и о чём нам говорит план выполнения? Сначала у нас 23 секунды читается с диска таблица. Потом с 23-й секунды до 50-й она сортируется. Очевидно, тоже на диске, т.к. в щедро выделенные 10 метров (work_mem) не помещается.

Да, проблема, действительно оказалась в установках, еще раз покрутив их было найдено вот такое сочетание, которое давало вполне приемлемые результаты выполнения запросов:

Еще раз огромное спасибо всем за советы и за варианты запросов!