Re: BUG #14020: row_number() over(partition by order by) - weird behavior

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #14020: row_number() over(partition by order by) - weird behavior
Дата
Msg-id CAKFQuwYpQJsLWBPRoR8+tA72aCUoV8cKX6eiN5dkSLeAtSWMTg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #14020: row_number() over(partition by order by) - weird behavior  (Boyko Yordanov <b.yordanov2@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: suzhengchun@gmail.com
Дата:
Сообщение: BUG #14023: pq odbc driver crashed while get data from boolean column
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: BUG #13440: unaccent does not remove all diacritics