'объясни мне postgresql - PullRequest
       18

'объясни мне postgresql

2 голосов
/ 11 декабря 2010

Получил вот этот запрос:

EXPLAIN
SELECT persons.id AS id, ppm.first
FROM myschema.persons
INNER JOIN myotherschema.ppm ON persons.key = ppm.pid
WHERE persons.id = 279759;

Столбец ppm.pid является первичным ключом И в индексе:

CREATE INDEX ppm_pkey_index
  ON myotherschema.ppm
  USING btree
  (pid);

Итак, вот ОБЪЯСНЕНИЕ:

Hash Join  (cost=8.31..3105.40 rows=306 width=23)
  Hash Cond: (textin(int4out(ppm.pid)) = persons.key)
  ->  Seq Scan on ppm  (cost=0.00..2711.33 rows=61233 width=23)
  ->  Hash  (cost=8.29..8.29 rows=1 width=12)
        ->  Index Scan using pskey on persons  (cost=0.00..8.29 rows=1 width=12)
              Index Cond: (id = 279759)

Кажется, что он вообще не использует ppm_pkey_index: он все еще сканирует 61 233 строки. Почему это? Я неправильно понимаю? Следствие: первичные ключи не индексируются автоматически в postgresql? Мой индекс тогда избыточен?

Ответы [ 2 ]

2 голосов
/ 11 декабря 2010

Первичные ключи создают УНИКАЛЬНЫЕ ИНДЕКСЫ на вашем ключе.Таким образом, ваш индекс действительно избыточен.

Запустили ли вы vacuum analyze на своей таблице после создания индекса?

sql> vacuum analyze myotherschema.ppm;

Теперь я вижу другую проблему: ppm.pid и persons.key изтот же тип поля?Вы можете столкнуться с проблемами perfomance из-за ненужных преобразований данных и невозможности использования индексов, поскольку вы не индексируете функции приведения, которые нужно использовать при объединении ...

0 голосов
/ 11 декабря 2010

Что произойдет, если вы измените его на:

EXPLAIN
SELECT persons.id AS id, ppm.first
FROM myschema.persons
INNER JOIN myotherschema.ppm ON persons.id = 279759
AND persons.key = ppm.pid;
...