On Mon, Dec 27, 2010 at 3:58 AM, Simon Riggs si...@2ndquadrant.com 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:
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_sort
On Thu, Dec 23, 2010 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kenneth Marshall k...@rice.edu 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
columns so slower thansortingon
one column?
On Thu, Dec 23, 2010 at 10:19:46PM +0800, Li Jie wrote:
Hi Ken,
Thanks for your tips! Yes it is the case, and I run another query sorting
on the second column whose values are random.
postgres=# explain analyze select * from big_wf
Kenneth Marshall k...@rice.edu 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
- Original Message -
From: Kenneth Marshall k...@rice.edu
To: Li Jie jay23j...@gmail.com
Cc: pgsql-hackers pgsql-hackers@postgresql.org
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
