X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id AA39552800
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Wed, 18 May 2005 14:52:19 -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 19775-01
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Wed, 18 May 2005 17:52:16 +0000 (GMT)
Received: from boutiquenumerique.com (boutiquenumerique.com [82.67.9.10])
	by svr1.postgresql.org (Postfix) with ESMTP id 29BA6528B3
	for <pgsql-sql@postgresql.org>; Wed, 18 May 2005 14:52:13 -0300 (ADT)
Received: (qmail 16278 invoked from network); 18 May 2005 19:52:41 +0200
Received: from unknown (HELO localhost) (boutiquenumerique-lists@192.168.0.4)
	by boutiquenumerique.com with SMTP; 18 May 2005 19:52:41 +0200
Date: Wed, 18 May 2005 19:52:14 +0200
To: Alain <alainm@pobox.com>, Sql-Postgre <pgsql-sql@postgresql.org>,
	Diogenes <di@sene.info>
Subject: Re: Changed to: how to solve the get next 100 records problem
References: 
 <DCD4903594CCF34CAFE200BDF3448D8D5B291A@tshuscodenmbx01.ERF.THOMSON.COM>
	<20050517170636.GC12405@phlogiston.dyndns.org>
	<428A2E81.2060501@pobox.com>
	<1116353539.26520.5.camel@localhost.localdomain>
	<428A3B54.4070902@pobox.com>
	<1116367382.9362.11.camel@localhost.localdomain>
	<428AA569.3010708@pobox.com>
	<1116404906.9362.19.camel@localhost.localdomain>
	<428B6263.5050402@pobox.com>
From: PFC <lists@boutiquenumerique.com>
Organization: =?iso-8859-15?Q?La_Boutique_Num=E9rique?=
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <op.sqzfxct8th1vuj@localhost>
In-Reply-To: <20050517170636.GC12405@phlogiston.dyndns.org>
User-Agent: Opera M2(BETA2)/8.0 (Linux, build 987)
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL
X-Spam-Level: 
X-Archive-Number: 200505/152
X-Sequence-Number: 21465



> The only strange thing is that without the 3rd order by, the order is  
> wrong. I didn't expect it because each select is created ordered. Is it  
> expected that UNION mixes it all up? (using postgre 7.4.1)

	That's because UNION removes duplicates, which it will probably doing  
using a hash (EXPLAIN ANALYZE is your friend).
	Use UNION ALL because your WHERE condition allows no duplicates anyway.  
UNION ALL preserves the order.
	So you can get the LIMIT out of the subqueries and put it around the  
UNION ALL.