X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id A4A1CD85D3
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri,  2 Sep 2005 17:08:56 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 52436-01
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri,  2 Sep 2005 20:08:54 +0000 (GMT)
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207])
	by svr1.postgresql.org (Postfix) with ESMTP id 81B70D85A7
	for <pgsql-performance@postgresql.org>;
	Fri,  2 Sep 2005 17:08:53 -0300 (ADT)
Received: by wproxy.gmail.com with SMTP id i23so123185wra
	for <pgsql-performance@postgresql.org>;
	Fri, 02 Sep 2005 13:08:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=UJzkGG0P3WX6kH7cgRTpY2f4uIu5CWcQoMGYZdlzJNIqYozHfa1ZPDicHOUX9uvrzO6cEvOn386f9hvIhp6s6C0kjfojFBuv3NeC7rOUjcXCYc/wE0XRTqapHlYqAS2GHI6uYpTNw46/OCWTUZcPziH3ScRKZo7g+2L+9oFuC9E=
Received: by 10.54.38.51 with SMTP id l51mr2323107wrl;
	Fri, 02 Sep 2005 13:08:53 -0700 (PDT)
Received: by 10.54.32.2 with HTTP; Fri, 2 Sep 2005 13:08:53 -0700 (PDT)
Message-ID: <bda43614050902130816116052@mail.gmail.com>
Date: Sat, 3 Sep 2005 01:38:53 +0530
From: Ramesh kumar <mbrameshkumar@gmail.com>
Reply-To: mbrameshkumar@gmail.com
To: Matteo Beccati <php@beccati.com>
Subject: Re: ORDER BY and LIMIT not propagated on inherited
Cc: Simon Riggs <simon@2ndquadrant.com>,
	pgsql-performance@postgresql.org
In-Reply-To: <43189B0F.2000904@beccati.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_99_32768915.1125691733300"
References: <43182789.4070307@beccati.com>
	<1125683697.3956.310.camel@localhost.localdomain>
	<43189B0F.2000904@beccati.com>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.239 required=5 tests=[AWL=0.159, HTML_30_40=0.056,
	HTML_MESSAGE=0.001, RCVD_BY_IP=0.024]
X-Spam-Level: 
X-Archive-Number: 200509/63
X-Sequence-Number: 14371

------=_Part_99_32768915.1125691733300
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi all
I have got lot of information from ur group.
Now i want to relieve from this group.
I kindly request all of you.
Plz unsubcribe me.
Thankz a lot
Ramesh

 On 9/3/05, Matteo Beccati <php@beccati.com> wrote:=20
>=20
> Simon Riggs wrote:
> > Returning to Matteo's original query, what we are saying is that the ne=
w
> > optimization for MIN/MAX queries doesn't work with inherited tables.
> >
> > It could do, by running optimize_minmax_aggregates() for each query tha=
t
> > gets planned to see if a better plan exists for each child table.
> >
> > I think that's a TODO item.
>=20
> Great. Of course I'm using ORDER BY ... LIMIT as a workaround to get the
> index scan on pre-8.1, and because I'm used to it insted of the
> previously not optimized MIN/MAX aggregates.
>=20
> > Optimizing ORDER BY and LIMIT down looks like it would be harder to do
> > in the general case, even if Matteo's simple transform looks good. I'm
> > not sure it's a very common query type though...
>=20
> If I can find some time, I'll try to write some hacks... I just need to
> find out where to start ;)
>=20
>=20
> Best regards
> --
> Matteo Beccati
> http://phpadsnew.com/
> http://phppgads.com/
>=20
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>=20



--=20
urs

RameshKumar.M

------=_Part_99_32768915.1125691733300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>Hi all</div>
<div>I have got lot of information from ur group.</div>
<div>Now i want to relieve from this group.</div>
<div>I kindly request all of you.</div>
<div>Plz unsubcribe me.</div>
<div>Thankz a lot</div>
<div>Ramesh<br><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 9/3/05, <b class=3D"gmail_sendername">M=
atteo Beccati</b> &lt;<a href=3D"mailto:php@beccati.com">php@beccati.com</a=
>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Simon Riggs wrote:<br>&gt; Retur=
ning to Matteo's original query, what we are saying is that the new<br>&gt;=
 optimization for MIN/MAX queries doesn't work with inherited tables.
<br>&gt;<br>&gt; It could do, by running optimize_minmax_aggregates() for e=
ach query that<br>&gt; gets planned to see if a better plan exists for each=
 child table.<br>&gt;<br>&gt; I think that's a TODO item.<br><br>Great. Of =
course I'm using ORDER BY ... LIMIT as a workaround to get the
<br>index scan on pre-8.1, and because I'm used to it insted of the<br>prev=
iously not optimized MIN/MAX aggregates.<br><br>&gt; Optimizing ORDER BY an=
d LIMIT down looks like it would be harder to do<br>&gt; in the general cas=
e, even if Matteo's simple transform looks good. I'm
<br>&gt; not sure it's a very common query type though...<br><br>If I can f=
ind some time, I'll try to write some hacks... I just need to<br>find out w=
here to start ;)<br><br><br>Best regards<br>--<br>Matteo Beccati<br><a href=
=3D"http://phpadsnew.com/">
http://phpadsnew.com/</a><br><a href=3D"http://phppgads.com/">http://phppga=
ds.com/</a><br><br>---------------------------(end of broadcast)-----------=
----------------<br>TIP 1: if posting/reading through Usenet, please send a=
n appropriate
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;subscribe-nomail command to <a href=
=3D"mailto:majordomo@postgresql.org">majordomo@postgresql.org</a> so that y=
our<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;message can get through to the m=
ailing list cleanly<br></blockquote></div><br><br clear=3D"all">
<br>-- <br>urs<br><br>RameshKumar.M=20

------=_Part_99_32768915.1125691733300--