Re: [PERFORM] Delete, foreign key, index usage

Поиск
Список
Период
Сортировка
От Johann Spies
Тема Re: [PERFORM] Delete, foreign key, index usage
Дата
Msg-id CAGZ55DTi5XqWdbbfWc_rRfzckUgZZoJBAd5Ku=0hagk-0xuNaQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PERFORM] Delete, foreign key, index usage  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: [PERFORM] Delete, foreign key, index usage  (David Rowley <david.rowley@2ndquadrant.com>)
Re: [PERFORM] Delete, foreign key, index usage  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-performance
On 24 April 2017 at 15:17, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
> On 04/24/2017 08:48 AM, Johann Spies wrote:
>>
>>
>> Why would the planner prefer the use the gin index and not the btree
>> index in this case?
>>
>
> You'll need to show what queries are you running - that's a quite important
> piece of information, and I don't see it anywhere in this thread. Seeing
> explain plans would also be helpful.

It is a simple "delete from wos_2017_1.article;" which causes a domino
effect deletes due to foreign keys. In the case of one table with more
than 50 million records where the primary key was also the foreign
key, the process only started to use the index when we built a gin
index.  In the case of the "belongs_to" table (shown in my first
email) we first built a btree index on the foreign key - and it was
ignored.  Only after the gin index was created did it use the index.

Regards.
Johann
--
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: [PERFORM] Questionaire: Common WAL write rates on busy servers.
Следующее
От: David Rowley
Дата:
Сообщение: Re: [PERFORM] Delete, foreign key, index usage