ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Считать ли багом (ORDER BY UNION)
4 сообщений из 4, страница 1 из 1
Считать ли багом (ORDER BY UNION)
    #33753824
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
нашол на днях некое ограничение SQL в постгре, которое можно посчитать и багом, а можно и не считать:

рассматривая как исполняецца запрос вида

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SELECT * FROM 
(SELECT  *
 FROM  table
WHERE ф<ф0
ORDER BY ф DESC, и DESC , о DESC
LIMIT  1 
UNION ALL
SELECT *
 FROM  table
WHERE ((ф = ф0) AND (и <и0))
ORDER BY ф DESC, и DESC , о DESC
LIMIT  1 ) AS foo
ORDER BY ф DESC, и DESC , о DESC
LIMIT  1 ;
наткнулся, что он попросту не просекаецца парсером. Токмо если модифицировать так:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SELECT * FROM 
(SELECT * FROM (SELECT  *
 FROM  table
WHERE ф<ф0
ORDER BY ф DESC, и DESC , о DESC
LIMIT  1 ) AS foo1
UNION ALL
SELECT * FROM (SELECT *
 FROM  table
WHERE ((ф = ф0) AND (и <и0))
ORDER BY ф DESC, и DESC , о DESC
LIMIT  1 ) AS foo2
) AS foo
ORDER BY ф DESC, и DESC , о DESC
LIMIT  1 ;
вот сидю и думаю - опраданы ли такие ограничения языка? (а кроме того и о предыстории такого своего "открытия" - почему запрос со сложным выбором, но с условием LIMIT 1 норовит отсортировать все полученное мн-во индексов (образующее непрерывную! область), не смотря на то , что в конце указано "ограничицца 1-й записью"? что, так сложно с математикой у разработчиков оптимизаторов?)
...
Рейтинг: 0 / 0
26.05.2006, 12:27
| Ответить | Цитировать | Написать  
Считать ли багом (ORDER BY UNION)
    #33757226
Владимор Конев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимор Конев
Участник
Дело в том, что LIMIT накладывается на результирующее множество уже после того, как проведены все остальные манипуляции, в том числе и сортировка. Ведь ты же по сути просишь сервер вернуть ПЕРВУЯ запись из УПОРЯДОЧЕННОГО определенным образом набора данных. Сервер на момент начала сортировки не знает, какая запись окажеться первой с учетом заданного порядка сортировки. Поэтому он вначале выполняет полную сортировку всего выходного набора данных и только после этого применяет LIMIT 1.
Так что, IMHO, всё вполне логично и честно со стороны сервера...
...
Рейтинг: 0 / 0
29.05.2006, 05:55
| Ответить | Цитировать | Написать  
Считать ли багом (ORDER BY UNION)
    #33757556
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
Владимор КоневДело в том, что LIMIT накладывается на результирующее множество уже после того, как проведены все остальные манипуляции, в том числе и сортировка.
...
Так что, IMHO, всё вполне логично и честно со стороны сервера...гм. А кто вам сказал, шо я этого не "понимаю". Но что мешает серверу нормально парсить
Код: plaintext
1.
2.
SELECT ... FROM .... ORDER BY ... LIMIT
UNION
SELECT ... FROM .... ORDER BY ... LIMIT
? Ведь всего-то надо распознать UNION в кач-ве разделителя отдельных полноценных селектов. Понятно, што это вопрос договоренностей (о синтаксисе). Например если _последний_ ордер бай при этом может рассматриваться как сортировка всего набора, то то , что лимит пишется (в силу особенностей синтаскиса) после сортировки вроде бы ограничивает возможность рассматривать "его" лимит как лимит только на последний селект, но для предыдущих наборов (хотя бы первого) этого ограничения нет? или я не прав? Хотя да, наверное запретить то, что нельзя для последнего и для всех прочих - видимо праильно.


т.ч., пораскинув, будем считать это особенностью синтаксиса с LIMIT супротив TOP.


Гораздо неприятнее то, что оптимизатор возьмется сортировать _всю отобранную начальным (безъюнионным) запросом область_, даже если она сплошна по составному индексу, и требуется вернуть лишь одну запись с границы отобранной области. на мой взгляд выяснить сплошна ли область (или даже вычислить набор сплошных областей по сложному, но константному условию) довольно несложно. А приведенный юнион просто позволяет свести все к индексному отбору граничных записей для сложного условия (и окончательного лимита) даже не прибегая к выяснению характера итоговой области "фильтрации" - подобную (по идее,но не буквально) технику тоже можно бы было реализовать унутре оптимизайции лимита.
...
Рейтинг: 0 / 0
29.05.2006, 10:43
| Ответить | Цитировать | Написать  
Считать ли багом (ORDER BY UNION)
    #33757617
Владимор Конев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимор Конев
Участник
4321 Владимор КоневДело в том, что LIMIT накладывается на результирующее множество уже после того, как проведены все остальные манипуляции, в том числе и сортировка.
...
Так что, IMHO, всё вполне логично и честно со стороны сервера...гм. А кто вам сказал, шо я этого не "понимаю". Но что мешает серверу нормально парсить
Код: plaintext
1.
2.
SELECT ... FROM .... ORDER BY ... LIMIT
UNION
SELECT ... FROM .... ORDER BY ... LIMIT
? Ведь всего-то надо распознать UNION в кач-ве разделителя отдельных полноценных селектов. Понятно, што это вопрос договоренностей (о синтаксисе). Например если _последний_ ордер бай при этом может рассматриваться как сортировка всего набора, то то , что лимит пишется (в силу особенностей синтаскиса) после сортировки вроде бы ограничивает возможность рассматривать "его" лимит как лимит только на последний селект, но для предыдущих наборов (хотя бы первого) этого ограничения нет? или я не прав? Хотя да, наверное запретить то, что нельзя для последнего и для всех прочих - видимо праильно.


т.ч., пораскинув, будем считать это особенностью синтаксиса с LIMIT супротив TOP.


Гораздо неприятнее то, что оптимизатор возьмется сортировать _всю отобранную начальным (безъюнионным) запросом область_, даже если она сплошна по составному индексу, и требуется вернуть лишь одну запись с границы отобранной области. на мой взгляд выяснить сплошна ли область (или даже вычислить набор сплошных областей по сложному, но константному условию) довольно несложно. А приведенный юнион просто позволяет свести все к индексному отбору граничных записей для сложного условия (и окончательного лимита) даже не прибегая к выяснению характера итоговой области "фильтрации" - подобную (по идее,но не буквально) технику тоже можно бы было реализовать унутре оптимизайции лимита.
Ход твоей мысли понял! Но, думаю, тут даже не разработчикам PostgeSQL вопрос. Тут нужно разработчикам стандарта ANSI-SQL сей вопрос задавать :)
Ведь в стандарте явно сказано - что если результирующий набор данных получается путем объединения нескольких множест итоговых данных (то есть с использованием операций над множетсвами UNION / UNION ALL), то предложение ORDER BY должно быть одно на весь итоговый датасет. Думаю, что причина нежелания работать у первого запроса кроится именно в этом следовании требованиям ANSI-SQL. :)
Хотя, конечно же, не понятно, почему в одном случае разработчики PostgreSQL следуют требованиям ANSI-SQL, а в другом - нет.
Всё, конечно же, сугубо личное IMHO.
...
Рейтинг: 0 / 0
29.05.2006, 11:06
| Ответить | Цитировать | Написать  
4 сообщений из 4, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Считать ли багом (ORDER BY UNION)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]