Правильный индекс находится на простых таблицах

У меня есть таблица в PostgreSQL 9.1:Правильный индекс находится на простых таблицах

_id   | integer | not null default nextval('"01f9073e-e6b8-46bf-882f-9a4cd0a69a66__id_seq"'::regclass) 
_full_text | tsvector | 
tlRecordID | text  | 
tlPDM   | text  | 
tlPayDateTime | text  | 
tlExpDateTime | text  | 
Indexes: 
    "01f9073e-e6b8-46bf-882f-9a4cd0a69a66_pkey" PRIMARY KEY, btree (_id) 
    "01f9073e-e6b8-46bf-882f-9a4cd0a69a66_tlRecordID_idx" UNIQUE, btree ("tlRecordID") 
    "01f9073e-e6b8-46bf-882f-9a4cd0a_tlPayDateTime_tlExpDateTime_idx" btree ("tlPayDateTime", "tlExpDateTime")

Там в ~ 35 млн. строк.

Вызов простой:

SELECT MAX("tlRecordID"::integer) AS max_id FROM "01f9073e-e6b8-46bf-882f-9a4cd0a69a66";

ли займет очень много времени. Кроме того, более сложные запросы, такие как:

FROM "01f9073e-e6b8-46bf-882f-9a4cd0a69a66" 
WHERE "tlPayDateTime" != 'None' AND "tlExpDateTime" != 'None' AND 
NOW() BETWEEN "tlPayDateTime"::timestamp AND "tlExpDateTime"::timestamp GROUP BY "tlPDM"

раз очень часто и т.д.

Может кто-нибудь поможет оптимизировать базу данных? 35 млн. строит проблему или?

источник

2013-11-25 user809829

это, возможно, поможет вам: http://stackoverflow.com/questions/11940515/postgres-performance-issues – funk

... Вы снимаете себе в ногу, используя тип символов на основе для хранения значения даты/времени (что '' None'' должно быть, должно быть, равно null). Кроме того, прочитайте [это сообщение в блоге] (http://sqlblog.com/blogs/aaron_bertrand/archive/2011/10/19/what-do-between-and-the-devil-have-in-common.aspx) для проблем, связанных с использованием 'BETWEEN' с отметками времени (сообщение специально относится к SQL Server, но логика применяется ко всем типам измерения/нецелого) –

Да, именно эти преобразования данных являются проблемой. Использование правильного типа данных является необходимым условием для производительности системы. –

Ненавижу приходить сюда с таким количеством критических замечаний, но я думаю, что устранение неполадок, как вы выразились, будет очень тяжело. У вас есть значительные ошибки в типах данных, которые приведут к тонким ошибкам и проблемам с производительностью, а также присвоение имен таблицам после GUID не является общей дорогой для удобства обслуживания.

Вам необходимо перенести ваши поля datetime в типы timestamp или timestamptz в зависимости от того, что вы хотите. Вы не получите хорошую производительность с ними в виде текстовых полей. Используйте NULL вместо «None»
Для вашего выбора максимального id просмотрите планы запросов. Мы не можем предоставить никаких отзывов. В идеале используйте VERBOSE и скажите, чтобы он также показывал использование буфера.
Вам не нужен литье рекласса. Брось это.

источник

2013-12-12 14:20:09

Правильный индекс находится на простых таблицах

ответ

Смежные вопросы