Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aT0vy-0002G7-D2 for pgsql-sql@arkaria.postgresql.org; Tue, 09 Feb 2016 05:33:54 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aT0vx-0000eT-GO for pgsql-sql@arkaria.postgresql.org; Tue, 09 Feb 2016 05:33:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aT0vv-0000cW-DQ for pgsql-sql@postgresql.org; Tue, 09 Feb 2016 05:33:51 +0000 Received: from mail-pf0-x231.google.com ([2607:f8b0:400e:c00::231]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aT0vr-0006Dy-W0 for pgsql-sql@postgresql.org; Tue, 09 Feb 2016 05:33:50 +0000 Received: by mail-pf0-x231.google.com with SMTP id c10so55117717pfc.2 for ; Mon, 08 Feb 2016 21:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=DRhlsnibXmSOMwU3yU7gas4A6WFeeEd1CJ+e3fIiPUs=; b=MOYHcVV7c/YxjeYfrQd9t5mkyXDxItaGNAUnkXehdxOqk7Enr0t90xkiSC4vr7BcGM vKGNfW3SOyVxNCxJZN0TDBNe2EAgscs8kxUgRO7t+BRw+Uv9r5dOzfavwy48ZgUyZQCc y5P0EiYc2HaKby+j/qJ1RvA9di6RhRUao7wGp8pyqi0pzVArf5Ix/SOK59KSPh+Jbwv2 LyVQeaRldf0S+5ebNd1FyDze2Ipun7FtSp2hmmR6VTEHt+63958Ikce8+/BIb/hRiFPR byjtrD9Xm4NqNXl0QgzIGu9ZMW6AaOdMGIZi+Nyi24SSNpyIN/UCuGM/y3WqguDJZnI9 GC2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=DRhlsnibXmSOMwU3yU7gas4A6WFeeEd1CJ+e3fIiPUs=; b=Tmk/pARIIXR6wlPROAOMtjA8wLEZZPbaYA9SfJ54pnj636HAHMZHNXPEE1MM+gE70f ZJK+inmINZhuyUvXkEfIRjb9AWEZP3Tj0DJZyNMXN1hMQRUY04VhYKq6dAYi8tdnH66Y hcVT2ekHE74WrKNcdlLF4mO2lccXPS8/dTGDRVfawBhVVIvpP3oP4Zc7vUXDAIxQKlO9 Xr0eCnh9khyo3zp1OZbyfrYte/AW3LFDnrXu9ocftKis3yfI212yotc/GWR3N7QSwXdc EC30vMIb+EaLZVAkc8v5ib0v8QIiSy1ljuKo4g7Y7m9Bwb68T49DgnzFMf1wM9c1vfej elNg== X-Gm-Message-State: AG10YOTCAmijcJx40x3wFOKCGpc5uG1hVcOS3pHKvEU42VABc5QY5/Uc65og6tICqAg0+Q== X-Received: by 10.98.68.193 with SMTP id m62mr47878541pfi.130.1454996025708; Mon, 08 Feb 2016 21:33:45 -0800 (PST) Received: from [155.100.214.120] ([155.100.214.120]) by smtp.gmail.com with ESMTPSA id c24sm36793758pfj.41.2016.02.08.21.33.44 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 21:33:44 -0800 (PST) Subject: Re: Question on PostgreSQL DB behavior w.r.t JOIN and sort order. To: pgsql-sql@postgresql.org References: <21082.1454994009@sss.pgh.pa.us> From: Rob Sargent Message-ID: <56B97A37.5010905@gmail.com> Date: Mon, 8 Feb 2016 22:33:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000401090705090901050008" X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org This is a multi-part message in MIME format. --------------000401090705090901050008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 02/08/2016 10:21 PM, Venkatesan, Sekhar wrote: > > Hi Tom, > > You can disregard the "TOP 10" modifier. That was added by me to bring > down the huge number of results being returned. > > Even without the TOP modifier, SQL server is returning rows in sorted > order (sorting columns based on the r_object_id (1^st ) column I > think) but PostgreSQL doesn’t. > > Is this anything to do with indexes? > > So from what I understand, you say in postgres, if the sort order is > not specified, postgres returns results in any order. Am I right? > > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Tuesday, February 09, 2016 10:30 AM > To: Venkatesan, Sekhar > Cc: pgsql-sql@postgresql.org > Subject: Re: [SQL] Question on PostgreSQL DB behavior w.r.t JOIN and > sort order. > > "Venkatesan, Sekhar" > writes: > > > I am seeing this behavior change in postgreSQL DB when compared to > SQL Server DB when JOIN is performed. The sort order is not retained > when JOIN is performed in PostgreSQL DB. > > What sort order? You did not specify any ORDER BY clause, so the DBMS > is entitled to return rows in any order it feels like. > > I do not know anything about this "top 10" modifier you've got in the > SQL Server version, but I suspect it's implying a sort order. In > Postgres, if you want a specific row ordering, you need to say ORDER BY. > > regards, tom lane > In my experience, this is ofter termed "disc order", implying what ever order the resultant tuples were discovered while processing the data. If MSSQL server is giving an order without explicit instruction to do so you may be incurring an unwanted sort operation. Is (any of) the data in a "clustered index": iirc that implies an on-disc ordering and the result set my be reflecting that. --------------000401090705090901050008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 02/08/2016 10:21 PM, Venkatesan, Sekhar wrote:

Hi Tom,

 

You can disregard the "TOP 10" modifier. That was added by me to bring down the huge number of results being returned.

Even without the TOP modifier, SQL server is returning rows in sorted order (sorting columns based on the r_object_id (1st) column I think) but PostgreSQL doesn’t.

Is this anything to do with indexes?

So from what I understand, you say in postgres, if the sort order is not specified, postgres returns results in any order. Am I right?

 

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, February 09, 2016 10:30 AM
To: Venkatesan, Sekhar
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] Question on PostgreSQL DB behavior w.r.t JOIN and sort order.

 

"Venkatesan, Sekhar" <sekhar.venkatesan@emc.com> writes:

> I am seeing this behavior change in postgreSQL DB when compared to SQL Server DB when JOIN is performed. The sort order is not retained when JOIN is performed in PostgreSQL DB.

 

What sort order?  You did not specify any ORDER BY clause, so the DBMS is entitled to return rows in any order it feels like.

 

I do not know anything about this "top 10" modifier you've got in the SQL Server version, but I suspect it's implying a sort order.  In Postgres, if you want a specific row ordering, you need to say ORDER BY.

 

                                                regards, tom lane

In my experience, this is ofter termed "disc order", implying what ever order the resultant tuples were discovered while processing the data.  If MSSQL server is giving an order without explicit instruction to do so you may be incurring an unwanted sort operation.  Is (any of) the data in a "clustered index": iirc that implies an on-disc ordering and the result set my be reflecting that.

--------------000401090705090901050008--