Re: slow dropping of tables, DropRelFileNodeBuffers, tas - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: slow dropping of tables, DropRelFileNodeBuffers, tas
Date
Msg-id CA+U5nMLdbU-7aX+AzCEuMFYhwMz1pSEOSrF0pM9sX1A6dxmCBw@mail.gmail.com
Whole thread Raw
In response to Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: slow dropping of tables, DropRelFileNodeBuffers, tas
List pgsql-hackers
On 7 June 2012 14:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sergey Koposov <koposov@ast.cam.ac.uk> writes:
>> On Tue, 5 Jun 2012, Simon Riggs wrote:
>>>>> Sounds less good and we'd need reasonable proof it actually did
>>>>> anything useful without being dangerous.
>
>>>> Doing an initial unlocked test speeds things up another 2.69 fold (on
>>>> top of 3.55 for your patch) for me, with 1GB of shared buffers.  That
>>>> seems like it should be worthwhile.
>
>>>> How do we go about getting reasonable proof that it is safe?
>
>>> That's enough for me.
>
> Say what?  That's a performance result and proves not a damn thing about
> safety.

Of course not.

Based on the rationale explained in the code comments in the patch, it
seems like a reasonable thing to me now.

The argument was that since we hold AccessExclusiveLock on the
relation, no other agent can be reading in new parts of the table into
new buffers, so the only change to a buffer would be away from the
dropping relation, in which case we wouldn't care. Which seems correct
to me.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: "page is not marked all-visible" warning in regression tests
Next
From: Tom Lane
Date:
Subject: Re: Avoiding adjacent checkpoint records