From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | bricklen <bricklen(at)gmail(dot)com> |
Cc: | "jonathan(dot)camile" <jonathan(dot)camile(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8629: Strange resultset when using CTE or a subselect |
Date: | 2013-11-26 17:22:08 |
Message-ID: | 9529.1385486528@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
bricklen <bricklen(at)gmail(dot)com> writes:
> On Tue, Nov 26, 2013 at 1:50 AM, jonathan.camile
> <jonathan(dot)camile(at)gmail(dot)com>wrote:
>> I always have the same last result regardless of the offset or the limit I
>> use.
> I cannot reproduce your problem in 9.2.5 nor 9.3.1. Rerunning the query
> with different OFFSET values gives me different results each time.
I do reproduce the behavior, at least when offset+limit is small enough
that the executor will use a top-N heapsort. As already stated, it's
not a bug; the ordering is underdetermined so any set of the correct
number of rows with status = 5 is a valid output. As for what's actually
happening: the row that always shows up seems to be the physically first
one with status = 5. I think that's starting out as the top of the top-N
heap, and it just stays there because there's nothing that can displace
it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-11-26 19:54:11 | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |
Previous Message | bricklen | 2013-11-26 16:52:04 | Re: BUG #8629: Strange resultset when using CTE or a subselect |