Re: performance issue in remove_from_unowned_list()

2019-03-26 Thread Tomas Vondra
On Thu, Mar 21, 2019 at 02:22:40AM +0100, Tomas Vondra wrote: ... OK, so here is a bit more polished version of the dlist-based patch. It's almost identical to what I posted before, except that it: 1) undoes the non-working optimization in DropRelationFiles() 2) removes

Re: performance issue in remove_from_unowned_list()

2019-03-20 Thread Tomas Vondra
On 3/12/19 11:54 PM, Tomas Vondra wrote: > > > On 3/10/19 9:09 PM, Alvaro Herrera wrote: >> On 2019-Feb-07, Tomas Vondra wrote: >> >>> Attached is a WIP patch removing the optimization from DropRelationFiles >>> and adding it to smgrDoPendingDeletes. This resolves the issue, at least >>> in the

Re: performance issue in remove_from_unowned_list()

2019-03-13 Thread Robert Haas
On Wed, Mar 13, 2019 at 9:47 AM Tomas Vondra wrote: > AFAICS we already maintain a hash table of the smgr relations, and we > look them up in this table. We don't need to look them up in the list of > unowned relations - the whole problem is that with the current > single-linked list, we need to

Re: performance issue in remove_from_unowned_list()

2019-03-13 Thread Tomas Vondra
On 3/13/19 1:12 PM, Robert Haas wrote: > On Tue, Mar 12, 2019 at 6:54 PM Tomas Vondra > wrote: >> Attached is a patch adopting the dlist approach - it seems to be working >> quite fine, and is a bit cleaner than just slapping another pointer into >> the SMgrRelationData struct. So I'd say this is

Re: performance issue in remove_from_unowned_list()

2019-03-13 Thread Robert Haas
On Tue, Mar 12, 2019 at 6:54 PM Tomas Vondra wrote: > Attached is a patch adopting the dlist approach - it seems to be working > quite fine, and is a bit cleaner than just slapping another pointer into > the SMgrRelationData struct. So I'd say this is the way to go. What about using a data

Re: performance issue in remove_from_unowned_list()

2019-03-12 Thread Tomas Vondra
On 3/10/19 9:09 PM, Alvaro Herrera wrote: > On 2019-Feb-07, Tomas Vondra wrote: > >> Attached is a WIP patch removing the optimization from DropRelationFiles >> and adding it to smgrDoPendingDeletes. This resolves the issue, at least >> in the cases I've been able to reproduce. But maybe we

Re: performance issue in remove_from_unowned_list()

2019-03-10 Thread Alvaro Herrera
On 2019-Feb-07, Tomas Vondra wrote: > Attached is a WIP patch removing the optimization from DropRelationFiles > and adding it to smgrDoPendingDeletes. This resolves the issue, at least > in the cases I've been able to reproduce. But maybe we should deal with > this issue earlier by ensuring the

Re: performance issue in remove_from_unowned_list()

2019-03-06 Thread Tomas Vondra
On 3/6/19 8:04 PM, Robert Haas wrote: > On Wed, Mar 6, 2019 at 1:53 PM Alvaro Herrera > wrote: >> On 2019-Feb-08, Tomas Vondra wrote: >>> I'm wondering if we should just get rid of all such optimizations, and >>> make the unowned list doubly-linked (WIP patch attached, needs fixing >>> the

Re: performance issue in remove_from_unowned_list()

2019-03-06 Thread Tomas Vondra
On 3/6/19 7:52 PM, Alvaro Herrera wrote: > On 2019-Feb-08, Tomas Vondra wrote: > >> I'm wondering if we should just get rid of all such optimizations, and >> make the unowned list doubly-linked (WIP patch attached, needs fixing >> the comments etc.). > > +1 for that approach. > > Did you

Re: performance issue in remove_from_unowned_list()

2019-03-06 Thread Robert Haas
On Wed, Mar 6, 2019 at 1:53 PM Alvaro Herrera wrote: > On 2019-Feb-08, Tomas Vondra wrote: > > I'm wondering if we should just get rid of all such optimizations, and > > make the unowned list doubly-linked (WIP patch attached, needs fixing > > the comments etc.). > > +1 for that approach. +1 for

Re: performance issue in remove_from_unowned_list()

2019-03-06 Thread Alvaro Herrera
On 2019-Feb-08, Tomas Vondra wrote: > I'm wondering if we should just get rid of all such optimizations, and > make the unowned list doubly-linked (WIP patch attached, needs fixing > the comments etc.). +1 for that approach. Did you consider using a dlist? -- Álvaro Herrera

Re: performance issue in remove_from_unowned_list()

2019-02-08 Thread Tomas Vondra
On 2/8/19 2:27 PM, Tomas Vondra wrote: > > > > On 2/8/19 12:32 PM, Ideriha, Takeshi wrote: >>> From: Tomas Vondra [mailto:tomas.von...@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

Re: performance issue in remove_from_unowned_list()

2019-02-08 Thread Tomas Vondra
On 2/8/19 12:32 PM, Ideriha, Takeshi wrote: >> From: Tomas Vondra [mailto:tomas.von...@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

RE: performance issue in remove_from_unowned_list()

2019-02-08 Thread Ideriha, Takeshi
>From: Tomas Vondra [mailto:tomas.von...@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

performance issue in remove_from_unowned_list()

2019-02-06 Thread Tomas Vondra
Hi, While working on benchmarks for the syscache patch (negative entries and all of that), I've ran into a an issue in remove_from_unowned_list. If you create a lot of relations in a single transaction (say, 100k) and then abort the transaction (or if it fails for some reason, e.g. because of