Обсуждение: Re: [pgsql-ru-general] Итерирование по таблице в режиме "Больше чем"
2016-12-14 10:44 GMT+01:00 Dmitry E. Oboukhov <unera@debian.org>:
есть таблица
"id" SERIAL
"did" INTEGER REFERENCES (NOT UNIQUE)
Таблица очень большая.
Нужен скрипт который обойдет данную таблицу по уникальным did, причем
желательно в порядке по возрастанию ID.
При этом желательно использовать индекс
Такое не подойдет?
--
Alex
Re: Re: [pgsql-ru-general] Итерирование по таблице в режиме "Больше чем"
От
"Dmitry E. Oboukhov"
Дата:
> есть таблица > "id" SERIAL > "did" INTEGER REFERENCES (NOT UNIQUE) > Таблица очень большая. > Нужен скрипт который обойдет данную таблицу по уникальным did, причем > желательно в порядке по возрастанию ID. > При этом желательно использовать индекс > Такое не подойдет? > https://wiki.postgresql.org/wiki/Loose_indexscan Насколько я понимаю будет ровно та же проблема из за SELECT MIN(col). То есть для unique индекса такой перебор вполне хорошо идет а вот для non-unique индекса перебор с выборкой unique заставляет брать min/max (от направления). а поскольку оно min/max планирует посортировать ПОСЛЕ выборки блока, то теоретически может сортируя оперировать большими объемами, а этого хочется избежать. Ведь выборка из BTREE с пропуском ненужных элементов сразу дает нужный, сортированный результат. -- . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Re: [pgsql-ru-general] Re: [pgsql-ru-general] Итерирование по таблице в режиме "Больше чем"
От
"Dmitry E. Oboukhov"
Дата:
> есть таблица > "id" SERIAL > "did" INTEGER REFERENCES (NOT UNIQUE) > Таблица очень большая. > Нужен скрипт который обойдет данную таблицу по уникальным did, причем > желательно в порядке по возрастанию ID. > При этом желательно использовать индекс > Такое не подойдет? > https://wiki.postgresql.org/wiki/Loose_indexscan Насколько я понимаю будет ровно та же проблема из за SELECT MIN(col). То есть для unique индекса такой перебор вполне хорошо идет а вот для non-unique индекса перебор с выборкой unique заставляет брать min/max (от направления). а поскольку оно min/max планирует посортировать ПОСЛЕ выборки блока, то теоретически может сортируя оперировать большими объемами, а этого хочется избежать. Ведь выборка из BTREE с пропуском ненужных элементов сразу дает нужный, сортированный результат. -- . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537