To: Marc Cousin <cousinmarc@gmail.com>
cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	pgsql-performance@postgresql.org
Subject: Re: inheritance: planning time vs children number vs column number 
In-reply-to: <201103010842.42128.cousinmarc@gmail.com> 
References: <201102281038.04945.cousinmarc@gmail.com>
	<201102281947.46590.cousinmarc@gmail.com>
	<4188.1298960419@sss.pgh.pa.us>
	<201103010842.42128.cousinmarc@gmail.com>
Comments: In-reply-to Marc Cousin <cousinmarc@gmail.com>
	message dated "Tue, 01 Mar 2011 08:42:42 +0100"
Date: Tue, 01 Mar 2011 10:33:51 -0500
Message-ID: <17604.1298993631@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Marc Cousin <cousinmarc@gmail.com> writes:
> Le mardi 01 mars 2011 07:20:19, Tom Lane a écrit :
>> It's worth pointing out that the only reason this effect is dominating
>> the runtime is that you don't have any statistics for these toy test
>> tables.  If you did, the cycles spent using those entries would dwarf
>> the lookup costs, I think.  So it's hard to get excited about doing
>> anything based on this test case --- it's likely the bottleneck would be
>> somewhere else entirely if you'd bothered to load up some data.

> Yes, for the same test case, with a bit of data in every partition and 
> statistics up to date, planning time goes from 20 seconds to 125ms for the 600 
> children/1000 columns case. Which is of course more than acceptable.

[ scratches head ... ]  Actually, I was expecting the runtime to go up
not down.  Maybe there's something else strange going on here.

			regards, tom lane