Re: slow dropping of tables, DropRelFileNodeBuffers, tas

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: slow dropping of tables, DropRelFileNodeBuffers, tas
Дата
Msg-id 28119.1339102321@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Sergey Koposov <koposov@ast.cam.ac.uk>)
Список pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
>> On 30 May 2012 12:10, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>> Also, I wonder if DropRelFileNodeBuffers() could scan the pool without
>>> grabbing the spinlocks on every buffer? It could do an unlocked test first,
>>> and only grab the spinlock on buffers that need to be dropped.

>> 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.

With shared_buffers set to 1GB, I see about a 2X reduction in the total
time to drop a simple table, iecreate table zit(f1 text primary key);drop table zit;
(This table definition is chosen to ensure there's an index and a toast
table involved, so several scans of the buffer pool are needed.)  The
DROP goes from about 40ms to about 20ms on a fairly recent Xeon desktop.
So I'm convinced this is a win.

I extended the patch to also cover DropDatabaseBuffers,
FlushRelationBuffers, and FlushDatabaseBuffers, which have got the exact
same type of full-pool scan loop, and committed it.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: WalSndWakeup() and synchronous_commit=off
Следующее
От: Tom Lane
Дата:
Сообщение: Re: slow dropping of tables, DropRelFileNodeBuffers, tas