Date: Thu, 18 Jan 2007 16:40:56 -0800 (PST)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Barbara Cosentino <bcosentino@ncircle.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Help ... Unexpected results when using limit/offset with
In-Reply-To: 
 <8A72E69E1F79004B82F76F228B3F29230637A623@corp-mail01.ncircle.com>
Message-ID: <20070118163103.R36654@megazone.bigpanda.com>
References: <8A72E69E1F79004B82F76F228B3F29230637A623@corp-mail01.ncircle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 18 Jan 2007, Barbara Cosentino wrote:

> Then I perform the following selects
>
> SELECT host_id, host_datum_type_id, host_datum_source_id, data
> FROM nc_host_datum  INNER JOIN nc_host USING (host_id)
> WHERE audit_id=2041
> ORDER BY host_id
> LIMIT 49 OFFSET 1372;
>
> And
>
> SELECT host_id, host_datum_type_id, host_datum_source_id, data
> FROM nc_host_datum  INNER JOIN nc_host USING (host_id)
> WHERE audit_id=2041
> ORDER BY host_id
> LIMIT 49 OFFSET 1421;
>
> A portion of the output follows.
>
>  host_id | host_datum_type_id | host_datum_source_id |     data
> ---------+--------------------+----------------------+--------------
>   :
>   :
>
>   963710 |                 58 |                   17| harrish
>   963711 |                 27 |                    3 | 1
>   963711 |                 28 |                    3 | 1
> (49 rows)
>
>
>  host_id | host_datum_type_id | host_datum_source_id |     data
> ---------+--------------------+----------------------+--------------
>   963711 |                 28 |                    3 | 1
>   963711 |                 58 |                   17 | lmitchel
>   963711 |                 39 |                    3 | us.aegon.com
> :
> :
> (49 rows)
>

> Notice that host_id = 963711 and host_datum_type_id = 28 is repeated
> twice.  Since the offset is not overlapping, how can this happen?

I'd suggest adding host_datum_type_id to the order by so that you have a
guarantee of the order that the rows for a given host_id will come,
otherwise I don't think you can assume anything within one host_id which
means you could get the same row at different effective offsets in
different runs of the base query (especially if you hit a point where the
plan changes).