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

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

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

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

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

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

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

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

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

Ога.

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

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

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

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

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

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

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

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

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

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

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

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

В том числе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ROFL Да уж...

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

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

не наш метод ;)

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

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

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

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

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

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

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

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

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

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

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

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

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

Какой? #11?

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

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

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

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

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

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