Re: Recovery performance of standby for multiple concurrent truncates on large tables

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recovery performance of standby for multiple concurrent truncates on large tables
Date: 2018-07-30 20:15:36
Message-ID: 20180730201536.o47bxmhlrs7mlquf@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-07-30 16:01:53 -0400, Robert Haas wrote:
> (1) Limit the number of deferred drops to a reasonably small number
> (one cache line? 1kB?).

Yea, you'd have to, because we'd frequently need to check it, and it'd
need to be in shared memory. But that'd still leave us to regress to
O(n^2) as soon as a transaction goes over that limit - which I don't
think is that infrequent...

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message 'Andres Freund' 2018-07-30 20:17:04 Re: Recovery performance of standby for multiple concurrent truncates on large tables
Previous Message Robert Haas 2018-07-30 20:01:53 Re: Recovery performance of standby for multiple concurrent truncates on large tables