RE: performance issue in remove_from_unowned_list()

Поиск
Список
Период
Сортировка
От Ideriha, Takeshi
Тема RE: performance issue in remove_from_unowned_list()
Дата
Msg-id 4E72940DA2BF16479384A86D54D0988A6F41EEA8@G01JPEXMBKW04
обсуждение исходный текст
Ответ на performance issue in remove_from_unowned_list()  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: performance issue in remove_from_unowned_list()  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
>From: Tomas Vondra [mailto:tomas.vondra@2ndquadrant.com]
>But it's a bit funnier, because there's also DropRelationFiles() which does smgrclose on
>a batch of relations too, and it says this
>
>    /*
>     * Call smgrclose() in reverse order as when smgropen() is called.
>     * This trick enables remove_from_unowned_list() in smgrclose()
>     * to search the SMgrRelation from the unowned list,
>     * with O(1) performance.
>     */
>    for (i = ndelrels - 1; i >= 0; i--)
>    ...
>
>but it's called from two places in xact.c only. And if you trigger the issue with 100k x
>CREATE TABLE + ROLLBACK, and then force a recovery by killing postmaster, you
>actually get the very same behavior with always traversing the unowned list for some
>reason. I'm not quite sure why, but it seems the optimization is exactly the wrong thing
>to do here.

So when DropRelationFiles() is called, order of calling smgr_close() and order of unowed list is always same?

This one was inroduced at b4166911 and I'd like to hear author and reviewer's opinion. 
https://www.postgresql.org/message-id/CAHGQGwH0hwXwrCDnmUU2Twj5YgHcrmMCVD7O%3D1NrRTpHcbtCBw%40mail.gmail.com

Regards,
Takeshi Ideriha

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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Commit Fest 2019-01 is now closed
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Inconsistent error handling in the openssl init code