From: | "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Tomas Vondra' <tomas(dot)vondra(at)2ndquadrant(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: performance issue in remove_from_unowned_list() |
Date: | 2019-02-08 11:32:52 |
Message-ID: | 4E72940DA2BF16479384A86D54D0988A6F41EEA8@G01JPEXMBKW04 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>From: Tomas Vondra [mailto:tomas(dot)vondra(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2019-02-08 11:37:48 | Re: Inconsistent error handling in the openssl init code |
Previous Message | Magnus Hagander | 2019-02-08 11:27:42 | Re: Commit Fest 2019-01 is now closed |