Как стать автором
Обновить

Комментарии 10

В целом все красиво, но, есть одно select * from table limit 0 работает дольше чем ручной обход схемы на больших таблицах. А вообще подход к решению шикарнейший. Меня остановил подобный путь чрезмерным расходом памяти. Хм, может перелинкуем наши решения?
Это можно, но учитывая, что я так долго писал статью, то с силами для объединения решений я соберусь еще не скоро =)
Ты же про линк на решение, что то я после 10 часов в автобусе невнимательный =) да конечно. я только за.
Глупый такой вопрос. Почему просто не сделать выборку SELECT… FROM A UNION B UNION C UNION D UNION ETC?
Особенно если учесть, что запрос select + group + count(*) + order by count(*) всё равно потребует full scan'а индекса (да какой нафиг индекса, если to_char еще накладывается), так что пользы от оптимизационного геморроя я что-то не вижу.
Промахнулся, ответил Вам ниже.
Вопрос не глупый. Такой вариант конечно рассматривался, однако поверьте мне на слово мой вариант работает быстрее. UNION — очень тяжеловесная операция, так как необходимо делать ORDER BY уже после объединения данных. Т.е. в моем варианте ORDER BY происходит для каждого столбца в отдельности за приемлимое время (однако не маленькое), а в случае с UNION эта сортировка происходит для всех данных вместе. Сравните: отсортировать 100 столбцов по миллиону записей в отдельности и отсортировать все эти данные после объединения. Выигрыш серьезный получается.
по крайней мере в CUBRID.
Я попробовал различные способы. Этот получился наиболее быстрым.
Много памяти жрет.
Знаю. Критерием была скорость. Если с учетом памяти, то другие решения лучше.
Нет, я про вариант с union :) А так — гораздо эффективней решение чем union. Нечто среднее — память/скорость. У меня скорость ниже, но памяти меньше расходуется.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.