RE: performance issue in remove_from_unowned_list()
Ideriha, Takeshi <ideriha.takeshi@jp.fujitsu.com>
From: "Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>
To: 'Tomas Vondra' <tomas.vondra@2ndquadrant.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-08T11:32:52Z
Lists: 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
Commits
-
Track unowned relations in doubly-linked list
- 31737eb43ffd 9.4.22 landed
- 261aa218c9a0 9.5.17 landed
- 0a5dcb87aec7 9.6.13 landed
- 5601f9fb97d1 10.8 landed
- fb0b5b0b84a0 11.3 landed
- 6ca015f9f073 12.0 landed