From: John Papandriopoulos <dr.jpap@gmail.com>
Subject: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps
	vmem compared to SELECT
Date: Sun, 05 Dec 2010 03:10:04 -0800
Organization: Hub.Org Networking Services
Lines: 16
Message-ID: <idfruc$aiq$1@news.hub.org>
References: <idbo6g$92r$1@news.hub.org> <14012.1291443654@sss.pgh.pa.us>
	<idd14l$a4u$1@news.hub.org> <23792.1291480923@sss.pgh.pa.us>
	<idec54$2hpd$1@news.hub.org> <13159.1291502400@sss.pgh.pa.us>
	<4CFACC81.3050901@vmsinfo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
	rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
In-Reply-To: <4CFACC81.3050901@vmsinfo.com>
To: pgsql-performance@postgresql.org

On 12/4/10 3:19 PM, Mladen Gogala wrote:
> Tom Lane wrote:
>> Partitioning using these techniques will work well with up to
>> perhaps a hundred partitions; don't try to use many thousands of
>> partitions.
>> regards, tom lane
> Hmmm, what happens if I need 10 years of data, in monthly partitions? It 
> would be 120 partitions. Can you please elaborate on that limitation? 
> Any plans on lifting that restriction?
> 

Even with 1k partitions, I don't have any issues any of the SELECT, UPDATE or DELETE queries and with 8GB RAM.

I suppose if you're using INSERT triggers, you'd want to make sure your plpgsql function is fast: I'm partitioning by power-of-two, so can use right-shift n-bits to quickly compute the insertion table name, rather than using an if-else-if chain.

John