Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id 83BFB632EA2
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri,  7 May 2010 12:35:53 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 12379-08
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri,  7 May 2010 15:35:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 15AFB632337
	for <pgsql-performance@postgresql.org>;
	Fri,  7 May 2010 12:35:45 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o47FZi5T013689;
	Fri, 7 May 2010 11:35:44 -0400 (EDT)
To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
cc: "Alexander Korotkov" <aekorotkov@gmail.com>,
	pgsql-performance@postgresql.org
Subject: Re: Planner issue on sorting joining of two tables with limit 
In-reply-to: <4BE3EAF60200002500031399@gw.wicourts.gov> 
References: <k2j2e2e4b141004251122u7adab639ve203afe7a486673f@mail.gmail.com>
	<5252.1272300692@sss.pgh.pa.us>
	<g2r2e2e4b141005030657vd6a0945fj9b9650bf515a189f@mail.gmail.com>
	<l2z2e2e4b141005052354p9bd81643j866bc5ce5af3ada5@mail.gmail.com>
	<4BE3EAF60200002500031399@gw.wicourts.gov>
Comments: In-reply-to "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
	message dated "Fri, 07 May 2010 10:27:02 -0500"
Date: Fri, 07 May 2010 11:35:43 -0400
Message-ID: <13688.1273246543@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201005/26
X-Sequence-Number: 38610

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Alexander Korotkov <aekorotkov@gmail.com> wrote:
>>> I just don't find why it is coincidence. I think that such plan
>>> will always produce result ordered by two columns, because such
>>> nested index scan always produce this result.
 
> Assuming a nested index scan, or any particular plan, is unwise. 

I think he's proposing that the planner should recognize that a plan
of this type produces a result sorted by the additional index columns.
I'm not convinced either that the sortedness property really holds,
or that it would be worth the extra planning effort to check for;
but it's not a fundamentally misguided proposal.

			regards, tom lane