Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
есть две таблицы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. а вот собственно сам хитрый запрос: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext Код: plaintext 1. 2. по QUERY PLAN такое чувство что просто игнорирует подселект Код: plaintext 1. 2. 3. 4. 5. собствено если закоментить одно условие в подселекте(которое по идеи не должно влиять на результат в данном случае) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext И в этом случае QUERY PLAN становится похож на правду Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Версия сервака 8,1,4 Помогите кто чем сможет. Заранее спасибо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 17:35 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Замена Код: plaintext Код: plaintext но что-то мне не нравится в вашем SQL'е. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 18:11 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
ThamerlanЗамена Код: plaintext Код: plaintext но что-то мне не нравится в вашем SQL'е. согласен, есть еще куча вариантов замен и переписи SQL, чтоб он отрабатывал правильно. Но что ему не нравится в исходном SQLе?? И как его заставить работать правильно не переписывая SQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 18:33 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
А не путает ли планировщик t1.ku_1 и test_1.ku_1 в подзапросе? Т. е. test_1 берётся не из запроса, а из подзапроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2007, 09:16 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
_Андрей_МА не путает ли планировщик t1.ku_1 и test_1.ku_1 в подзапросе? Т. е. test_1 берётся не из запроса, а из подзапроса? В том то и дело что не путает, а по QUERY PLAN он подзапрос просто игнорирует. Что -то я вообще перестал понимать как работает сервак, в этом случае ему плевать на case и он выдает все строки , хотя по идее результат СКЛ ничего не должен вернуть, т.к. нет записей с ku = -1 и test_1.ku = null. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. а вот если заменить Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2007, 12:32 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Ну, я так понимаю, что походу это все-таки ошибка планировщика или оптимизатора. Ни у кого, больше ни каких мыслей нет? Интересно версия 8.2 себя также ведет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 10:18 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
8.2.0 тоже возвращает все 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2007, 11:52 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
8.2.4 под winXP тоже. Интересно, что Код: plaintext 1. 2. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 08:47 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Похоже, а понял в чём дело. У Вас таблицы в подзапросе связаны с таблицей в основном запросе, соответственно, select min(t1.ku) отрабатывает не для всей таблицы (точнее, соединения таблиц), а только для текущей записи. Хотя, тогда непонятно, почему IN работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 09:10 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
_Андрей_МПохоже, а понял в чём дело. У Вас таблицы в подзапросе связаны с таблицей в основном запросе, соответственно, select min(t1.ku) отрабатывает не для всей таблицы (точнее, соединения таблиц), а только для текущей записи. Хотя, тогда непонятно, почему IN работает. По идее подзапрос и должен отрабатывать для каждой строки, и для каждой строки должен вернуть минимальную t1.ku , в данном случае одну и ту же, равной единице. Но видимо сервер думает что умнее нас, типа ему подсовывают "масло - масляное" и подзапрос вообще не выполняет. Если в СКЛ добавить явную ошибку, то он все равно отработает)). Код: plaintext 1. 2. 3. 4. 5. 6. Помогает еще ему прочухаться конвертирование test_1.ku в другой тип, например с test_1.ku::int8 = (select min(t1.ku) тоже отрабатывает правильно Мне кажется что оптимизатор ошибочно думает что условие test_1.ku = test_2.ku равнозначно условию test_1.ku = (select min(t1.ku) . Типа тут избыточность и он не исполняет подзапрос. Как видно ему помагает изменение каких либо условий сравнения предикатов. Например изменение сравнения для подзапроса на in или конвертирование типа test_1.ku ( в одном из условий сравнения ), а вот если написать так Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 10:48 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Vivka Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. я ваще-то не понимаю, что вы тут обсуждаете, потому как обсуждать работу Код: plaintext если же имеется в виду какое-то другое написание запроса - приведите. будем посмотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 10:54 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
4321я ваще-то не понимаю, что вы тут обсуждаете, потому как обсуждать работу Код: plaintext если же имеется в виду какое-то другое написание запроса - приведите. будем посмотреть. ОК. test_1.ku = case when test_1.ku is null заменить на test_1.ku = case when test_1.name is null . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 11:08 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Я имел в виду, что в подзапросе обрабатывается одна запись. А для одной записи min(t1.ku) = t1.ku. Так как записи запроса и подзапроса связаны, то для Петрова min(t1.ku) = 1, для Иванова - 2, для Сидорова - 3. Вот они все и выводятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 11:53 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
проверил на oracle, действительно, такое ощущение что pg просто откидывает часть условия с подзапросом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 12:06 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Если б записи запроса и подзапроса были связаны по ku - то согласен, а они связаны по ku_1 !. Т.Е по логике у подзапроса есть три аргумента test_1.ku_1 , test_2.kh, test_2.d_s, и все три аргумента, для всех вариантов записей запроса, имеют одинаковое значение 0, 1, '2007-01-01', и подзапрос по идеи должен для каждой записи запроса приводится к виду Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 12:13 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
st_sergпроверил на oracle, действительно, такое ощущение что pg просто откидывает часть условия с подзапросом... Ну да я тоже проверял и на SYBASE и на MSSQL. Все отрабатывают как надо, один pg умничает)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 12:15 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Vivka st_sergпроверил на oracle, действительно, такое ощущение что pg просто откидывает часть условия с подзапросом... Ну да я тоже проверял и на SYBASE и на MSSQL. Все отрабатывают как надо, один pg умничает))если Вы ещё не написали багрепорт, пожалуйста, напишите его вот сюда: http://archives.postgresql.org/pgsql-bugs/ (форма для отправки багрепорта собственно тут - http://www.postgresql.org/support/submitbug ) приложите к сообщению об ошибке схему базы и тестовые данные (как в Вашем первом сообщении, только русский текст лучше заменить на транслит так как не у всех есть русские шрифты) ps: если Вам трудно написать по английски - пожалуйста напишите по русски сдесь (или мне личным сообщением) - я переведу на английский и отправлю багрепорт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 12:36 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Не писал и не буду, с английским туго. Если у кого есть желания написать, пишите. В принципе вся инфа есть в первом сообщении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 12:52 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
отправил кстати, нашёл помоему похожую ошибку - http://archives.postgresql.org/pgsql-bugs/2007-07/msg00073.php ("Query Error : plan should not reference subplan's" - уже исправили вроде, по крайней мере там есть патч Тома) про проблемы с min max и "the older code for Param assignment". я не особо вникал, посмотри, может быть это аналогично тому с чем ты столкнулся и может этот патч тебе поможет :) -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 14:46 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Ёшотправил Запостите пожалуйста URL на созданный вами BR. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 15:07 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Ёш про проблемы с min max ну, если переписать на ORDER .. DESC LIMIT 1 - проблема остается забавный бажок. чинится вот так (лишние поля я выводил для посмотреть): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 15:52 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Уже кто-то отпостил багрепорт. Посмотрим, что умные люди скажут :) Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 15:56 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Thamerlan Ёшотправил Запостите пожалуйста URL на созданный вами BR. http://archives.postgresql.org/pgsql-bugs/2007-07/msg00136.php ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 16:04 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Dan BlackУже кто-то отпостил багрепорт. Посмотрим, что умные люди скажут :) Код: plaintext 1. Интересно, что в селекте подзапроса можно прибавить что-нить к величине - подзапрос все равно не выполняется (если не прибавлять 0 к правой части). а вот если переписать на джойн - то бага не будет. (если я, конечно же, правильно навскид переписал): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. и еще - при прибавлении 0 справа - имеем план похожий на замену =() на IN() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 16:53 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Если уж говорить о сложных запросах, то вышеописанный запрос ужасен на мой взгляд :) Есть очень много спорных подходов, касающихся подзапроса и его использования в основном запросе (из серии почему используется =(), а не IN () )... да и сам подзапрос, а именно условия Код: plaintext 1. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 17:01 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Dan BlackЕсли уж говорить о сложных запросах, то вышеописанный запрос ужасен на мой взгляд :) Есть очень много спорных подходов, касающихся подзапроса и его использования в основном запросе (из серии почему используется =(), а не IN () )... да и сам подзапрос, а именно условия Код: plaintext 1. Код: plaintext 1. На самом деле в оригинальном СКЛ это все обязательное и на все таблицы есть необходимые индексы. Я просто составил простой скл что было понятно. Да и еще, для теущего примера замена test_1.ku = (select min(t1.ku) на test_1.ku IN (select min(t1.ku) помогает а вот в ориганльном СКЛ нет, все так же не цепляет подзапрос Помагает только test_1.ku + 0 = (select min(t1.ku) или test_1.ku::int8= (select min(t1.ku) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 17:24 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Вот например с in тоже не работает. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2007, 17:54 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
вот тут удалось получить тот же баг в более простом выражении: http://archives.postgresql.org/pgsql-bugs/2007-07/msg00141.php пишут - имеет место для 8.1 и 8.2 , пора переходить на 8.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 10:30 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
тут еще проще. http://archives.postgresql.org/pgsql-bugs/2007-07/msg00143.php У кого с англ. хорошо , что там в конце написал tom lane, переведите плиз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 13:24 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
It appears that join_clause_is_redundant() is rejecting the clause as redundant. I suppose some part of that machinery gets confused by the fact that the RHS of the clause references both relations. The EquivalenceClass rewrite cleaned this whole area up greatly, so no surprise that the bug is gone in HEAD. No time to look at it more now. -- Похоже, что join_clause_is_redundant() откидывает оператор как избыточный. Я думаю, что алгоритм спотыкается, когда правая часть оператора содержит ссылки на обе таблицы. В HEAD, скорее всего, баг пропал вследствии значительных изменений в EquivalenceClass. На дальнейшие разборки пока нет времени. ps. не пинайте ногами :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 13:41 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
Vivkaтут еще проще. http://archives.postgresql.org/pgsql-bugs/2007-07/msg00143.php У кого с англ. хорошо , что там в конце написал tom lane, переведите плиз. Ну это и есть ответ на bug-report, посланный Ёш. Том считает, что функция ответственная за отбрасывание лишних операций в WHERE блоке сходит с ума от того, что в правой части сравнения (right-hand side) фигурируют обе таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 13:45 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
st_serg опередил :) Именно это и я имел в виду ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 13:47 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
ThamerlanТом считает, что функция ответственная за отбрасывание лишних операций в WHERE блоке сходит с ума от того, что в правой части сравнения (right-hand side) фигурируют обе таблицы.мдя-с. кто-то настрогал левую математику. Так как, в 8.3. усе будет пучком? Или я чего-то не понял? (уш плюха, так плюха. хоть людЯм не кажись - засмеють...) кстати, кажется проскакивала инфа о предполагаемом релизе 8.3 в начале июля, или я что-то путаю? Если не путаю - что не ладится? зы. не пробовал кто-нть этот тестик на 7-ке (от 7.3 и выше)? там тоже чудесатости? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 14:21 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
4321 кстати, кажется проскакивала инфа о предполагаемом релизе 8.3 в начале июля, или я что-то путаю? Если не путаю - что не ладится? roadmap:PatchStatus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2007, 18:55 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
о развернулась целая дискуссия.. http://archives.postgresql.org/pgsql-bugs/2007-07/msg00156.php http://archives.postgresql.org/pgsql-bugs/2007-07/msg00159.php http://archives.postgresql.org/pgsql-bugs/2007-07/msg00161.php В последнем сообщении вроде обещает исправить в следущем релизе. только когда он будет интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 11:06 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
... it'll be in the next set of releases -- ... он войдет в следующий набор релизов насколько я понимаю, это будет 8.2.5, 8.1.10 и тд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 11:23 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
4321 кстати, кажется проскакивала инфа о предполагаемом релизе 8.3 в начале июля, или я что-то путаю? Если не путаю - что не ладится? когда-то давно (а именно в начале цикла 8.3) все мечтали о короткой итерации и релизе в июне, да сейчас речь идет об октябре все ладится, кроме того, что полгода назад недооценили количество и сложность предполагаемых к релизу патчей, летний спад активности и некоторые другие банальные вещи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 00:01 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
<pgsql-announce@postgresql.org> - Fix a bug in the original implementation of redundant-join-clause removal: clauses in which one side or the other references both sides of the join cannot be removed as redundant, because that expression won't have been constrained below the join. Per report from Sergey Burladyan. CVS HEAD does not contain this bug due to EquivalenceClass rewrite, but it seems wise to include the regression test for it anyway. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2007, 10:33 |
|
||
|
помогите определится у кого ошибка
|
|||
|---|---|---|---|
|
#18+
up ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2007, 10:57 |
|
||
|
|

start [/forum/topic.php?all=1&fid=53&tid=2004928]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 219ms |
| total: | 380ms |

| 0 / 0 |
