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
