Решение задачи второго конкурса CUBRID it!

[@Ekstazi]

В целом все красиво, но, есть одно select * from table limit 0 работает дольше чем ручной обход схемы на больших таблицах. А вообще подход к решению шикарнейший. Меня остановил подобный путь чрезмерным расходом памяти. Хм, может перелинкуем наши решения?

[@mubinov]

Это можно, но учитывая, что я так долго писал статью, то с силами для объединения решений я соберусь еще не скоро =)

[@mubinov]

Ты же про линк на решение, что то я после 10 часов в автобусе невнимательный =) да конечно. я только за.

[@datacompboy]

Глупый такой вопрос. Почему просто не сделать выборку SELECT… FROM A UNION B UNION C UNION D UNION ETC?

[@datacompboy]

Особенно если учесть, что запрос select + group + count(*) + order by count(*) всё равно потребует full scan'а индекса (да какой нафиг индекса, если to_char еще накладывается), так что пользы от оптимизационного геморроя я что-то не вижу.

[@mubinov]

Промахнулся, ответил Вам ниже.

[@mubinov]

Вопрос не глупый. Такой вариант конечно рассматривался, однако поверьте мне на слово мой вариант работает быстрее. UNION — очень тяжеловесная операция, так как необходимо делать ORDER BY уже после объединения данных. Т.е. в моем варианте ORDER BY происходит для каждого столбца в отдельности за приемлимое время (однако не маленькое), а в случае с UNION эта сортировка происходит для всех данных вместе. Сравните: отсортировать 100 столбцов по миллиону записей в отдельности и отсортировать все эти данные после объединения. Выигрыш серьезный получается.
по крайней мере в CUBRID.
Я попробовал различные способы. Этот получился наиболее быстрым.

[@Ekstazi]

Много памяти жрет.

[@mubinov]

Знаю. Критерием была скорость. Если с учетом памяти, то другие решения лучше.

[@Ekstazi]

Нет, я про вариант с union :) А так — гораздо эффективней решение чем union. Нечто среднее — память/скорость. У меня скорость ниже, но памяти меньше расходуется.