Re: slow dropping of tables, DropRelFileNodeBuffers, tas

Поиск
Список
Период
Сортировка
От Sergey Koposov
Тема Re: slow dropping of tables, DropRelFileNodeBuffers, tas
Дата
Msg-id alpine.LRH.2.02.1206011107001.26221@calx046.ast.cam.ac.uk
обсуждение исходный текст
Ответ на Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Fri, 1 Jun 2012, Simon Riggs wrote:

>
> Why do you have 10,000 tables and why is it important to drop them so quickly?

10000 tables are there, because that's the number of partitions. And I'm 
dropping them at the moment, because I'm doing testing. So it won't be
really crucial for production. But I still thought it was worth reporting. 
Especially when the table dropping took .5 a sec.

The problem is that when I set up the shared_buffers say to 48G, the 
timings of the tables rise significantly again.

> If its that important, why not run the drop in parallel sessions?

Yes, before there was a strong reason to do that, now the timings are more 
manageable, but maybe I'll implement that.

Cheers,    S

*****************************************************
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA, Cambridge, UK
Tel: +44-1223-337-551 Web: http://www.ast.cam.ac.uk/~koposov/


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque
Следующее
От: Sergey Koposov
Дата:
Сообщение: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile