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

From Sergey Koposov
Subject Re: slow dropping of tables, DropRelFileNodeBuffers, tas
Date
Msg-id alpine.LRH.2.02.1206011107001.26221@calx046.ast.cam.ac.uk
Whole thread Raw
In response to Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: slow dropping of tables, DropRelFileNodeBuffers, tas  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Checkpointer starts before bgwriter to avoid missing fsync reque
Next
From: Sergey Koposov
Date:
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile