@rise, Никаких первичных ключей нет? Хоть OID может есть?

@rise, Я бы через временную таблицу попробовал.

@rise, дубликаты навернуть чтоле?

@norguhtar, Ога.

@datacompboy, Антон, SELECT DISTINCT в другую табличку, снести всё из исходной, а потом вернуть — разве не покатит?

@rise, дубликаты совсем одинаковые или все же первичный ключ есть?

@stanis, покатит. но требует другую табличку. а мы решаем хитрые ж пути :)

@datacompboy, первичный ключ есть. и есть поле с дублирующимися значениями. нужно оставить только первый из дубликатов, удалив остальные. вот точная формулировка задачи.

@datacompboy, А нам эффект нужен или с червами и трефами? :)

@rise, Чего select distinct отменили уже в постгре?

@rise, делаем селект с группировкой по всем дублирующимся полям, далее по primary key берем max(id) или min(id). В результате получаем список id которые не надо удалять. Далее в delete вызываем where id not in (наш запрос)

@NetMoose, и что он сударь вам даст?

@norguhtar, Искомое, сударь.

@norguhtar, Выбор во временную табличку даст, сударь.

@stanis, а если таблица внезапно на миллиард записей? :)

@norguhtar, Мы куда-то торопимся?

@norguhtar, Тогда список id-шников внезапно не влезет в максимальный размер запроса.

@stanis, Планировщик как бе обычно умнее и переколбашивает как надо запрос, так что такого прикола не будет.

@stanis, И кстати, даже если и влезет, устанешь ждать когда в этом случае конструкция where id not in (наш запрос) отработает.

@NetMoose, Имхо в любом случае простая выборка, DELETE FROM и вставка быстрее будут.

@NetMoose, сотни раз так делал и как-то не уставал.

@stanis, эм. Товарищи вы там чо MySQL пользуетесь даа?

@norguhtar, Постоянно с миллиардами записей? Круто...

@norguhtar, В том числе.

@stanis, по вашей теории оно должно на наворачиваться на 10 тысячах :]

@norguhtar, Мы там пользуемся MS SQL, Oracle 9i, MySQL и PosgreSQL тоже иногда бывает.

@NetMoose, У нас ещё и DB/2 было в начале века.

@NetMoose, как бе вообще планировщик такое переколбашивает сам, прежде чем выполнять иначе если все делать в лоб будет трындец производительности.

@norguhtar, На планировщика надейся, а сам не плошай.

@NetMoose, в этом случае прийдется сильно зубодробительный DELETE писать. А так вполне себе работает и переколбашивается.

@norguhtar, В варианте со временной табличкой ничего не зубодробительный. DELETE FROM sometable. Экстремально зубодробительно, да.

@stanis, я не про таблицу временную а про развертывание select в delete. Да такое можно сделать, но лучше не думать про это. Временная же табличка в случае если надо удалить мало overhead.

@norguhtar, Что такое "мало overhead"? Как-то не слишком по-русски. Смысл предложения я не понял вообще.

@norguhtar, Спасибо большое, сделал вот так как ты сказал. Супер. =)

@stanis, тфу. Дольше отрабатывать будет и сильнее диск насиловать. Вообщем прежде чем что-то делать я бы оценил количество дубликатов и возможно добавил бы еще одну связку в select чтобы получить то что надо удалить. Т.е. чтоб операция была просто in. Если дубликатов мало, то такая операция пройдет быстрее. Если их столько сколько обычных записей, то можно и через табличку. Скорость получим ту же.

@norguhtar, Я машинально подумал, что дубликатов больше. Раз эдак в несколько. Шаблон мышления.

@norguhtar, Там 50 записей, из них примерно у каждого третьего есть 1 дубликат.

@rise, вот на таких случаях городить табличку дополнительную не надо точно.

@rise, Всего??? :))) Тогда вообще не принципиально же! ;)))) А мы тут миллиарды записей обсуждаем.

@stanis, И да, доп. табличка тут вообще нафиг не нужна.

@stanis, ROFL Да уж...

@NetMoose, =) ну вот, я сделал по методу в 11-м комментарии.

@rise, В твоем кокретном случае даже руками было бы недолго.

@NetMoose, не наш метод ;)

@rise, Ага. "Лучше день потерять, потом за пять минут долететь" © Орел из "Крылья, ноги, хвосты" ;)

@rise, Кстати, я вспомнил, откуда у меня эта идея про временную табличку. Мы так реально большую таблицу на боевом сервере от дубелей чистили. Выборка, очистка, залили обратно. Очень быстро получились второй и третий шаги.

@NetMoose, Ну просто когда в следующий раз у меня возникнет такая проблема — я за 5 минут ее "долечу", неважно на каких масштабах )

@stanis, 2 с хреном миллиарда записей на боевом сервере. Тот же способ, время простоя минимальное.

@NetMoose, Какой? #11?

@rise, Ну-ну. Желаю не разочароваться в способе.

@stanis, Нет. С временной таблицей.

@NetMoose, Почему я в нем могу разочароваться? ) в этой таблице в принципе не будет больше 1000 записей..

@rise, Сам сказал: "Неважно, на каких масштабах".

@stanis, Неважно, 50 или 1000. А так да, для миллионных таблиц этот способ будет медленным.

@rise, Вы не планируете больше ни с какой таблицев по жизни общаться?

@NetMoose, Тьфу. Таблицей.

@rise, 1000 для БД — это тот же масштаб. Зовётся по-русски "хрен да маленько".

@NetMoose, Планирую. Но этот способ именно для моего частного конкретного случая — идеален )

@rise, Ок, дискуссия потеряла смысл ) Спасибо всем за подсказки )

@rise, datacompboy: основное для max()/min() выборок с группировками индексы, без них всё ляжет, это факт

@rise, Ну просто если планируете, то последуйте совету: планировщик — это не человек и даже не машина, чтобы не разочароваться очень сильно не стоит на него возлагать много надежд.