Re: BUG #14020: row_number() over(partition by order by) - weird behavior - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: BUG #14020: row_number() over(partition by order by) - weird behavior
Date
Msg-id CAKFQuwYpQJsLWBPRoR8+tA72aCUoV8cKX6eiN5dkSLeAtSWMTg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14020: row_number() over(partition by order by) - weird behavior  (Boyko Yordanov <b.yordanov2@gmail.com>)
List pgsql-bugs
On Tue, Mar 15, 2016 at 2:04 AM, Boyko Yordanov <b.yordanov2@gmail.com>
wrote:

> Thinking further on this, I now got your point on the =E2=80=9Cduplicate
> grossprices is ordered randomly=E2=80=9D suggestion.
>
> What I missed to realize is that the update query updates *every* product
> partition that has reordered due to duplicate grossprice being ordered
> randomly, resulting in thousands of updates instead of just < 148 (or < 9=
9
> in the case of product =3D 2 partition).
>
> Is there a way to ensure persistence of =E2=80=9Cover(order by duplicate_=
columns)=E2=80=9D
> ordering, except for ordering by a second (or even third) column?
>
>
=E2=80=8BNo, you need to have enough columns for deterministic order.

Dave
=E2=80=8B

pgsql-bugs by date:

Previous
From: suzhengchun@gmail.com
Date:
Subject: BUG #14023: pq odbc driver crashed while get data from boolean column
Next
From: Teodor Sigaev
Date:
Subject: Re: BUG #13440: unaccent does not remove all diacritics