Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id F08DB1337B93 for ; Tue, 1 Mar 2011 11:39:31 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 71177-07 for ; Tue, 1 Mar 2011 15:39:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mimolette.dalibo.net (unknown [212.85.154.222]) by mail.postgresql.org (Postfix) with ESMTP id B34E91337B96 for ; Tue, 1 Mar 2011 11:39:20 -0400 (AST) Received: from marco-dalibo.localnet (gev44-1-78-228-108-65.fbx.proxad.net [78.228.108.65]) by mimolette.dalibo.net (Postfix) with ESMTPSA id 04EF1D8331; Tue, 1 Mar 2011 16:39:20 +0100 (CET) From: Marc Cousin To: Tom Lane Subject: Re: inheritance: planning time vs children number vs column number Date: Tue, 1 Mar 2011 16:39:19 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.37-ARCH; KDE/4.6.0; x86_64; ; ) Cc: Heikki Linnakangas , pgsql-performance@postgresql.org References: <201102281038.04945.cousinmarc@gmail.com> <201103010842.42128.cousinmarc@gmail.com> <17604.1298993631@sss.pgh.pa.us> In-Reply-To: <17604.1298993631@sss.pgh.pa.us> X-KMail-Markup: true MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-01=_nMRbNs4bJOaBVXo" Content-Transfer-Encoding: 7bit Message-Id: <201103011639.19396.cousinmarc@gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.105 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RDNS_NONE=0.793 X-Spam-Level: X-Archive-Number: 201103/11 X-Sequence-Number: 42690 --Boundary-01=_nMRbNs4bJOaBVXo Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable The Tuesday 01 March 2011 16:33:51, Tom Lane wrote : > Marc Cousin writes: > > Le mardi 01 mars 2011 07:20:19, Tom Lane a =C3=A9crit : > >> 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. > >=20 > > 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. >=20 > [ scratches head ... ] Actually, I was expecting the runtime to go up > not down. Maybe there's something else strange going on here. >=20 > regards, tom lane Then, what can I do to help ? --Boundary-01=_nMRbNs4bJOaBVXo Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

The Tuesday= 01 March 2011 16:33:51, Tom Lane wrote :

> Marc C= ousin <cousinmarc@gmail.com> writes:

> > L= e mardi 01 mars 2011 07:20:19, Tom Lane a =C3=A9crit :

> >&g= t; It's worth pointing out that the only reason this effect is dominating

> >&g= t; the runtime is that you don't have any statistics for these toy test

> >&g= t; tables. If you did, the cycles spent using those entries would dwarf

> >&g= t; the lookup costs, I think. So it's hard to get excited about doing

> >&g= t; anything based on this test case --- it's likely the bottleneck would be=

> >&g= t; somewhere else entirely if you'd bothered to load up some data.

> > <= /p>

> > Y= es, for the same test case, with a bit of data in every partition and

> > s= tatistics up to date, planning time goes from 20 seconds to 125ms for

> > t= he 600 children/1000 columns case. Which is of course more than

> > a= cceptable.

> [ scra= tches head ... ] Actually, I was expecting the runtime to go up

> not do= wn. Maybe there's something else strange going on here.

> reg= ards, tom lane

Then, what = can I do to help ?

--Boundary-01=_nMRbNs4bJOaBVXo--