Re: Speedup of relation deletes during recovery

Hi,

On 2018-06-27 15:56:58 +1200, Thomas Munro wrote:
> That's a different code path that eats a lot of CPU on the *primary*, because:

While that's obviously not great, I think it's far less dangerous than
the standby having worse complexity than the primary. There's an obvious
backpressure if commands on the primary take a while, but there's
normally none for commands with high complexity on the standby...


>                 /*
>                  * Normally, we need a transaction-safe truncation
> here.  However, if
>                  * the table was either created in the current
> (sub)transaction or has
>                  * a new relfilenode in the current (sub)transaction,
> then we can just
>                  * truncate it in-place, because a rollback would
> cause the whole
>                  * table or the current physical file to be thrown away anyway.
>                  */
>                 if (rel->rd_createSubid == mySubid ||
>                         rel->rd_newRelfilenodeSubid == mySubid)
>                 {
>                         /* Immediate, non-rollbackable truncation is OK */
>                         heap_truncate_one_rel(rel);
>                 }
>                 else
> 
> Without range-scannable buffer mapping (Andres's radix tree thing),
> that bet doesn't work out too well when you do it more than once.
> Hmm... we could just... not do that?

That'd probably hurt noticably too...


> (Has anyone ever looked into a lazier approach to dropping buffers?)

What precisely are you thinking of? We kinda now do something lazy-ish
at EOXact...

Greetings,

Andres Freund