Re: Speedup of relation deletes during recovery - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Speedup of relation deletes during recovery
Date
Msg-id 20180615182834.zmvvrybuptwba3na@alap3.anarazel.de
Whole thread Raw
In response to Re: Speedup of relation deletes during recovery  (Andres Freund <andres@anarazel.de>)
Responses Re: Speedup of relation deletes during recovery
List pgsql-hackers
Hi,

On 2018-06-15 10:45:04 -0700, Andres Freund wrote:
> > +
> > +    srels = palloc(sizeof(SMgrRelation) * ndelrels);
> >      for (i = 0; i < ndelrels; i++)
> > -    {
> > -        SMgrRelation srel = smgropen(delrels[i], InvalidBackendId);
> > +        srels[i] = smgropen(delrels[i], InvalidBackendId);
> >  
> > -        smgrdounlink(srel, false);
> > -        smgrclose(srel);
> > -    }
> > +    smgrdounlinkall(srels, ndelrels, false);
> > +
> > +    for (i = 0; i < ndelrels; i++)
> > +        smgrclose(srels[i]);
> > +    pfree(srels);

Hm. This will probably cause another complexity issue. If we just
smgropen() the relation will be unowned. Which means smgrclose() will
call remove_from_unowned_list(), which is O(open-relations). Which means
this change afaict creates a new O(ndrels^2) behaviour?

It seems like the easiest fix for that would be to have a local
SMgrRelationData in that loop, that we assign the relations to?  That's
a bit hacky, but afaict should work?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Removing "Included attributes in B-tree indexes" section from docs
Next
From: Amit Khandekar
Date:
Subject: Re: AtEOXact_ApplyLauncher() and subtransactions