а есть какой-нибудь инструмент, чтобы построил структуру базы диаграммкой? ну типа связи таблиц и тд и тп?

pgModeler

Но он своеобразный

а есть какой-нибудь инструмент, чтобы построил структуру базы диаграммкой? ну типа связи таблиц и тд и тп?

dbwrench

Результат неопределён.

Почему?

Почему?

ORDER BY

ЕМС умеет, кстати

ORDER BY

Ну и что?

И годно делает

Ну и что?

Ну и то.

Ну и то.

Что "то"?

Что "то"?

When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows

When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows

И как это влияет на данный конкретный запрос? ;)

простите, а разве оффсет/лимит работают до аггрегации?

ребят какой из joinov работает быстрей?

И как это влияет на данный конкретный запрос? ;)

Ничего не знаю. Говорю в соответствии с документацией. Не определён.

Во, какая жаркая дискуссия. Мне это и надо )

Ничего не знаю. Говорю в соответствии с документацией. Не определён.

Со всем уважением, но Вы её не поняли.

В конечном итоге OFFSET исключит единственную результирующую строку из выборки

Со всем уважением, но Вы её не поняли.

Да ладно? Где?

простите, а разве оффсет/лимит работают до аггрегации?

Именно после аггрегации, поэтому и ничего не будет

ааа, значит не показалось

Да ладно? Где?

Вот здесь: Otherwise you will get an unpredictable subset of the query's rows. Здесь есть (максимум) 1 row в результате, затем [в произвольном порядке] пропускается 2, и выводится 4. Какой будет result set?

Вот здесь: Otherwise you will get an unpredictable subset of the query's rows. Здесь есть (максимум) 1 row в результате, затем [в произвольном порядке] пропускается 2, и выводится 4. Какой будет result set?

Какая именно строка в результате?

Какая именно строка в результате?

Не имеет значения, разве нет? Возьмите, например, два объекта, расставьте их в произвольном порядке, затем отбростьте 3 и выдайте 5. Какой будет результат?

ребят какой из joinov работает быстрей?

для двух больших сетов merge иначе nested loop

Не имеет значения, разве нет? Возьмите, например, два объекта, расставьте их в произвольном порядке, затем отбростьте 3 и выдайте 5. Какой будет результат?

Ну так если Вы не можете назвать конкретную строку, значит результата Вы не знаете. Значит он неопределён. Ч.т.д.

Ну так если Вы не можете назвать конкретную строку, значит результата Вы не знаете. Значит он неопределён. Ч.т.д.

а что, например, может вернуть запрос с картинки по вашему? ну например?

просто интересно

можно даже парочку вариантов ответов возможных

Ну так если Вы не можете назвать конкретную строку, значит результата Вы не знаете. Значит он неопределён. Ч.т.д.

Е-р-у-н-д-а. Перечитайте мой пример. Я Вам больше скажу, SQL стоит на / состоит из unspecified behaviour в значительной степени... и, тем не менее, запросы-то мы как-то пишем. ;)

а что, например, может вернуть запрос с картинки по вашему? ну например?

Результат неопределён. Это не по-моему, это согласно документации.

Результат неопределён. Это не по-моему, это согласно документации.

что значит не опеределен?

и

Е-р-у-н-д-а. Перечитайте мой пример. Я Вам больше скажу, SQL стоит на / состоит из unspecified behaviour в значительной степени... и, тем не менее, запросы-то мы как-то пишем. ;)

Ну так пишем же мы с ORDER BY.

Ну так пишем же мы с ORDER BY.

как переписать запрос, чтобы результат был опеределен?

Добавить ORDER BY.

Пусть ?

от этого результат как-то поменяется?

нет )

Ну так пишем же мы с ORDER BY.

В данном случае, это не имеет значения.

нет )

мне интересна цепочка рассуждений от молодого человека выше)

ну или это просто бот-статический анализатор кода

я не бот )

я не бот )

запрос-то что вернет?

вон там и ордер есть

от этого результат как-то поменяется?

Вы, видимо не поняли. Без ORDER BY хоть пусть будет OFFSET 100500 - результат неопрелён. Не важно, сколько записей отфильтрутся. Пустое множество - это тоже множество ?

ничего он не вернет, даже если отсортировать по part все равно перед обрезкой будет одна запись

Вернёт два поля 1 и 110

А стлп

Блядь

1 и 40

Кто вообще пишет offset до limit?

Вы, видимо не поняли. Без ORDER BY хоть пусть будет OFFSET 100500 - результат неопрелён. Не важно, сколько записей отфильтрутся. Пустое множество - это тоже множество ?

тут вполне определенные данные и ответ вполне себе определен, и не важно, есть тут order by или его нет. более того, даже если в конкретно данном случае убрать оффсеты, то ордер бай все-равно не удет играть никакой роли. это как считать, что select count(*) from table будет давать разные результаты при разной сортировке

А, нет, все верно, 1 и 110

Вы, видимо не поняли. Без ORDER BY хоть пусть будет OFFSET 100500 - результат неопрелён. Не важно, сколько записей отфильтрутся. Пустое множество - это тоже множество ?

Выглядит так, что в рамках этого запроса результат всегда опередлён. Т.е. сколько бы раз вы не запускали этот код, результат будет один и тот же.

Выглядит так, что в рамках этого запроса результат всегда опередлён. Т.е. сколько бы раз вы не запускали этот код, результат будет один и тот же.

Это существенное замечание - "выглядит так".

А разве он сначала не отберёт поля по лимиту а потом просуммирует?

тут вполне определенные данные и ответ вполне себе определен, и не важно, есть тут order by или его нет. более того, даже если в конкретно данном случае убрать оффсеты, то ордер бай все-равно не удет играть никакой роли. это как считать, что select count(*) from table будет давать разные результаты при разной сортировке

Это не ко мне вопрос. Вот что говорит документация - When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows

Да, точно. Я писал такие запросы. Сначала посчитает сумму, а потом уже будет брать лимиты

Это не ко мне вопрос. Вот что говорит документация - When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows

да чего вы прикопались к этой строчке? тут не говорится, что ответ будет неопределен, а говорится что "может быть разным", но при этом может быть и одинаковым

Это не ко мне вопрос. Вот что говорит документация - When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows

Даже не знаю, что вам сказать. Может быть посоветовать вам ещё раз посмотреть запрос, ведь там есть фильтрация и группировка по фильтрации и offset со значением > 1.

да чего вы прикопались к этой строчке? тут не говорится, что ответ будет неопределен, а говорится что "может быть разным", но при этом может быть и одинаковым

"Может быть" === неопреледённость.

нет

Даже не знаю, что вам сказать. Может быть посоветовать вам ещё раз посмотреть запрос, ведь там есть фильтрация и группировка по фильтрации и offset со значением > 1.

Но ORDER BY то нет.

Но ORDER BY то нет.

я добавил в запрос order by. ответ становится определенным?

или это троллинг такой?

Но ORDER BY то нет.

Ну ок, теперь я могу только сказать: ? Удачи

нет

Нет? Ну 2 + 2 = 4. Без всяких "может быть". Это детерминированный результат. Факт объективной реальности. Доказанный.

Но ORDER BY то нет.

вот тут ответ определен? select part, sum(value) from table t where part=1 group by part order by part offset 2 limit 4

Нет? Ну 2 + 2 = 4. Без всяких "может быть". Это детерминированный результат. Факт объективной реальности. Доказанный.

вы там под веществами чтоли?

вот тут ответ определен? select part, sum(value) from table t where part=1 group by part order by part offset 2 limit 4

Да, тут определён.

Да, тут определён.

и какой же?

и какой же?

Пустое множество.

Вы, видимо не поняли. Без ORDER BY хоть пусть будет OFFSET 100500 - результат неопрелён. Не важно, сколько записей отфильтрутся. Пустое множество - это тоже множество ?

Это Вы неправильно понимаете, к сожалению. Здесь Вам не С, понятия undefined behavior в SQL нет. Вот что написано в стандарте, например: Implementation-dependent: Possibly differing between SQL-implementations, but not specified by this International Standard and not required to be specified by the implementor for any particular SQL-implementations. When the ordering of a cursor is not defined by an <ORDER BY clause>, the relative position of two rows is implementation-dependent.

Это Вы неправильно понимаете, к сожалению. Здесь Вам не С, понятия undefined behavior в SQL нет. Вот что написано в стандарте, например: Implementation-dependent: Possibly differing between SQL-implementations, but not specified by this International Standard and not required to be specified by the implementor for any particular SQL-implementations. When the ordering of a cursor is not defined by an <ORDER BY clause>, the relative position of two rows is implementation-dependent.

Да, но ведь implementation (PostgreSQL) уже высказалась по этому поводу в документации. Я ведь Вам приводил отрывок.

Вообще, этот спор бессмысленный.

я так и вижу как делаю выборку по примари кею и обязательно вставляю сортировку, а то вдруг какая-то херня придет

я так и вижу как делаю выборку по примари кею и обязательно вставляю сортировку, а то вдруг какая-то херня придет

Вы делаете выборку по первичному ключу, указывая LIMIT?

Вы делаете выборку по первичному ключу, указывая LIMIT?

конечно, limit 1 offset 0

сразу после сортировки

конечно, limit 1 offset 0

По первичному ключу?

Вообще, этот спор бессмысленный.

Ничего подобного! И высказывание это не говорит, что в этих случаях PostgreSQL может Вам возвращать всякий бред, который с запросом никак не сзязан. Более того, ISO SQL прямо запрещает такие шутки, как мне помнится.

По первичному ключу?

как будто так делать нельзя

Ничего подобного! И высказывание это не говорит, что в этих случаях PostgreSQL может Вам возвращать всякий бред, который с запросом никак не сзязан. Более того, ISO SQL прямо запрещает такие шутки, как мне помнится.

PostgreSQL выдаст неопрелённый результат в случае LIMIT без ORBER BY. Нет, ну если, как говорит коллега, сделать SELECT * FROM foo WHERE id = 10 LIMIT 1 OFFSET 0, то тут PostgreSQL деваться будет некуда, хотя формально, результат будет неопределён. Правда я честно не понимаю зачем его тут делать неопределённым с помощью LIMIT...

Хм... интересно, если в таблице test есть колонки a, b, c. И я делаю такой запрос: selec ctid, a,b,c from test order by a, b, c offset 5 limit 10 Всегда одно одно и то же будет?

PostgreSQL выдаст неопрелённый результат в случае LIMIT без ORBER BY. Нет, ну если, как говорит коллега, сделать SELECT * FROM foo WHERE id = 10 LIMIT 1 OFFSET 0, то тут PostgreSQL деваться будет некуда, хотя формально, результат будет неопределён. Правда я честно не понимаю зачем его тут делать неопределённым с помощью LIMIT...

Запросто, таблица с полными дублями без pk на id

Запросто, таблица с полными дублями без pk на id

Ну вот тут уже видно опыт ))

Хм... интересно, если в таблице test есть колонки a, b, c. И я делаю такой запрос: selec ctid, a,b,c from test order by a, b, c offset 5 limit 10 Всегда одно одно и то же будет?

нет

Который сын ошибок всмысле )

Хм... интересно, если в таблице test есть колонки a, b, c. И я делаю такой запрос: selec ctid, a,b,c from test order by a, b, c offset 5 limit 10 Всегда одно одно и то же будет?

Если компаратор типа данных не говорит равно на неидентичные строки

Не "неопределённый результат", а результат LIMIT-а, кторый применён к rows, отсортированным в произвольном порядке. Т.е. если у Вас, например, есть: "... LIMIT 3;" и без LIMIT возвращается больше трёх rows, возрат двух — это, безусловно, bug в СУБД. И ещё раз, здесь Вам не C. ;)