Чтобы сократить время запроса

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

а точно надо эти 50М строк выковыривать, если из них только 10К будет использовано? Нельзя ли как-то разбить на части, по-другому пофильтровать? Тупо перечитать столько строк с диска - уже все время и уйдет туда.

ага, ищутся дубли SELECT "t1"."item", Count("t1"."item") AS count FROM "itemstemp" AS t1 GROUP BY "t1"."item" ORDER BY count DESC LIMIT 10000;

HAVING?

Тогда те строки что по 1 разу можно не выбирать

SELECT "t1"."item", Count("t1"."item") AS count FROM "itemstemp" AS t1 GROUP BY "t1"."item" HAVING Count("t1"."item")>1

В вашем запросе - если дублей будет 10 штук - то выведет 9990 недублей все равно

прости пожалуйста если обижу

и если оффтоп

но твоё имя это как бы говорили "массив" если бы была картавость?

типа array

)) Ну типа того ))

прикольно)

Думаю имя еще с тех времен когда массивов небыло... но кортавость наверняка была

ну вот

теперь буду гуглить что появилось раньше

массив или твоё имя

занял меня на вечер

HAVING?

забыл, спасибо

забыл, спасибо

вторым этапом будет сделать explain

сделал быстрее не стало

сделал быстрее не стало

Однако, сильный ход.

А о чем план говорит?

Даже на моём 30" мониторе ни хрена не разобрать на этом скриншоте.

а воркмем и шаред бафферс сколько ?

А если work_mem увеличить?

set work_mem to '2GB';

+

shared_buffers = 2GB work_mem = 34952kB

set work_mem to '2GB';

41 секунда

попробуй увеличить, work_mem до гига хотя бы

Всего у вас 13к строк после having

ну и shared_buffers задрать побольше

И план новый в студию

А то опять нечитаемо

это после set work_mem to '2GB';

Странно, что опять диск использует

указал в конфигах shared_buffers = 4GB work_mem = 2GB перезапустил так же

а размер базы какой ?

3,2 гига

забавно

Есть индекс по полю item?

указал по 4гб стало 37 секунд

но теперь сжирает озу

Есть индекс по полю item?

индексов нет после них запрос минуты две идет поле bigint

У вас одинаковые значения в поле item на сколько часто встречаются?

указал по 4гб стало 37 секунд

без временного файла

У вас одинаковые значения в поле item на сколько часто встречаются?

на этот вопрос ответ примерно такой: как повезет

А можно создать индекс по полю item и прислать план запроса?

не понимаю как там индекс поможет... там же count

А можно создать индекс по полю item и прислать план запроса?

+1, от сортировки на диске можно избавиться с помощью индекса

не понимаю как там индекс поможет... там же count

куча обрабатываться иначе чем seq scan не может а вот индекс - легко Другой разговор - что решит делать СУБД

вот с индексом

и видимо уперется в CPU

=)

попробуйте индекс кластеризовать

попробуйте индекс кластеризовать

вот

стало хуже почему то

Да нет, всё правильно. Там же IndexOnlyScan

тогда не нужны индексы выходит

ERROR: S client not available

вообще странно, что планировщик выбрал план с индексом, но запрос стал работать в полтора раза медленнее. Может дело в статистике?

vacuum analyze можно прогнать

а СPU usage что показывает при выполнении ?

и теперь он без временного файла, есть по 2гб озу на запрос хотя конфиг вернул к начальному

какой нить atop

а СPU usage что показывает при выполнении ?

htop

Ну как бе вот и ответ...

так он и без индексов упиравется в ядро как писал выше но делает запрос за 45-50 секунд

вообще странно, что планировщик выбрал план с индексом, но запрос стал работать в полтора раза медленнее. Может дело в статистике?

Там на 50м записей 47м уникальных

так он и без индексов упиравется в ядро как писал выше но делает запрос за 45-50 секунд

+ временный файл создает

Там на 50м записей 47м уникальных

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

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

Да

а версия пг какая ?

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

Тут вообще берется вся таблица - и индекс для выборки не используется - только для сортировки

в 9.6 агрегаты норм параллеляться

если без фанатизма

и не очень нажимать

в теории можно и секционировать табличку

это если партиции есть нормальные

в теории можно и секционировать табличку

нужно, план сразу лучше станет

в 9.6 агрегаты норм параллеляться

да уж, нормально :)

в 9.6 агрегаты норм параллеляться

9.6

по нагрузке на цпу чтот не заметно

хотя какие настройки ?

да уж, нормально :)

ну если не очень напирать на это то норм ;)

в теории можно и секционировать табличку

это как?

хотя какие настройки ?

если вы про max_worker_processes и max_parallel_workers_per_gather то я их задавал 8 и 4 соответственно ядра грузились но лучше не стало

ядра или ядро

в плане была параллельность

?