On Mon, Dec 27, 2010 at 3:58 AM, Simon Riggs wrote:
> I think the answer is that only the first column comparison is
> optimised. Second and subsequent comparisons are not optimised.
What sort of optimization are you referring to here?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
Th
On Fri, 2010-12-24 at 00:27 -0500, Jie Li wrote:
> I doubt the cost of comparing two integers is the issue here;
> rather
> it's more likely one of how many merge passes were needed.
> You could
> find out instead of just speculating by turning on trace_sor
On Thu, Dec 23, 2010 at 10:26 AM, Tom Lane wrote:
> Kenneth Marshall writes:
> > On Thu, Dec 23, 2010 at 10:42:26PM +0800, Li Jie wrote:
> >> But in the last query that sorts on "id", since the query selects all
> the columns for output, the actual sorted size is the same, and the only
> differ
- Original Message -
From: "Kenneth Marshall"
To: "Li Jie"
Cc: "pgsql-hackers"
Sent: Thursday, December 23, 2010 10:30 PM
Subject: Re: [HACKERS] Why is sorting on two columns so slower thansortingon
one column?
> On Thu, Dec 23, 2010 at 10:19:46
Kenneth Marshall writes:
> On Thu, Dec 23, 2010 at 10:42:26PM +0800, Li Jie wrote:
>> But in the last query that sorts on "id", since the query selects all the
>> columns for output, the actual sorted size is the same, and the only
>> difference is the comparison cost. The query sorting on two
On Thu, Dec 23, 2010 at 10:42:26PM +0800, Li Jie wrote:
> - Original Message -
> From: "Kenneth Marshall"
> To: "Li Jie"
> Cc: "pgsql-hackers"
> Sent: Thursday, December 23, 2010 10:30 PM
> Subject: Re: [HACKERS] Why is sorting on t
