Re: slow dropping of tables, DropRelFileNodeBuffers, tas

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: slow dropping of tables, DropRelFileNodeBuffers, tas
Дата
Msg-id CA+U5nMLdbU-7aX+AzCEuMFYhwMz1pSEOSrF0pM9sX1A6dxmCBw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: "page is not marked all-visible" warning in regression tests
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Avoiding adjacent checkpoint records