Re: Delete performance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Delete performance
Дата
Msg-id 11337.1140618701@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Delete performance  (Arnau <arnaulist@andromeiberica.com>)
Ответы Re: Delete performance  (Arnau <arnaulist@andromeiberica.com>)
Список pgsql-admin
Arnau <arnaulist@andromeiberica.com> writes:
>> The usual cause of slow deletes is that (a) the table is the target of
>> some foreign key references from other large tables, and (b) the
>> referencing columns in those tables aren't indexed.

>    This is a thing I don't understand, as far as I know the foreign keys
> references to primary keys and postgresql creates itself and index over
> the primary key, so those columns always should be indexed. Taking into
> account Tom's observation I'm missing something, could you explain it to
> all of us :)

The referencED column is forced to have an index.  The referencING
column is not.  The cases where you need an index on the latter are
precisely updates/deletes of the referencED column.

In the old version you are using you can also get burnt by datatype
mismatches --- the foreign key mechanism will allow that as long as
it can find an equality operator for the two types, but that equality
operator might not be indexable.

            regards, tom lane

В списке pgsql-admin по дате отправления:

Предыдущее
От: "Jayaram Bhat"
Дата:
Сообщение: unsubscribe
Следующее
От: CG
Дата:
Сообщение: WARNING: foreign key constraint will require costly sequential scans during pg_restore