On Tue, 16 Oct 2007 20:47:41 +0400, Vlad Khorsun <[EMAIL PROTECTED]> wrote:
>>> "A" лучше натуралом перебирать. Попробуй убедить его в этом >> >> Я пробовал и PLAN SORT (JOIN (A NATURAL, A1 INDEX (PK_TABLE1))), >> и даже PLAN SORT (JOIN (A NATURAL, A1 NATURAL)) >> На результат не влияет. И LEFT JOIN тоже пробовал. >> >> На 1.0.3 _все_ варианты плана, даже с двумя натуралами, отрабатывают >> максимум за 5 секунд. > > Кинь мне бекап (или БД) с одной этой таблицей У меня воспроизводится на свежесозданной базе/таблице, состоящей из одного только ID (он же PK). Заливаю туда 10 тыс. записей, генератором, и вуаля. Я тут подумал ещё раз. По идее, join по такому условию и должен считать порядка 8848*8849/2 = 39 млн. записей (прогрессия арифметическая). Разница только в двух "not exists" в условии. Join с группировкой, без "not exists" выполняется одинаково на обоих серверах. На 2-ке "not exists" умножают число чтений на 2, получаем 78 млн., а на 1-це почему-то усекают число чтений всего лишь до 88 тыс., что и отрабатывает мухой. У меня свежи воспоминания, как нарвался на разницу работы "in (select" в 1-це и 2-ке, и теперь знаю, что этот селект выполняется в 2-ке как derived. Может, и с exists тут какая-то похожая засада? -- Сергей Смирнов.
