Re: drop/truncate table sucks for large values of shared buffers

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: drop/truncate table sucks for large values of shared buffers
Date: 2015-07-02 13:12:37
Message-ID: 20150702131237.GA16267@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-07-02 16:08:03 +0300, Heikki Linnakangas wrote:
> I'm marking this as "returned with feedback" in the commitfest. In addition
> to the issues raised so far, ISTM that the patch makes dropping a very large
> table with small shared_buffers slower (DropForkSpecificBuffers() is O(n)
> where n is the size of the relation, while the current method is
> O(shared_buffers))

I think upthread there was talk about only using the O(relsize) approach
if relsize << NBuffers. That's actually a pretty common scenario,
especially in testsuites.

> I concur that we should explore using a radix tree or something else that
> would naturally allow you to find all buffers for relation/database X
> quickly.

I unsurprisingly think that's the right way to go. But I'm not sure if
it's not worth to add another layer of bandaid till were there...

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-07-02 13:18:47 Re: drop/truncate table sucks for large values of shared buffers
Previous Message Andrew Dunstan 2015-07-02 13:08:07 Re: raw output from copy