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()
|
Список | 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 по дате отправления: