s
Seq Scan on csco_ifndq У вас тут гадит по большей части
Size: a a a
2020 August 21
s
Ну и просто вагон перебираемых данных, которые в кеш не влезают и диск насилуют
YS
если железа выделят побольше, партиционность таблиц поможет? тк сейчас в качестве эксперимента csco_idesind_2008_2020 это кусок csco_idesind, а там данные с 1993 года, если с ней начать работы...
Только если большинство запросов относятся к небольшому подмножеству partitions (и это можно точно определить на этапе их планирования / выполнения!). Иначе будет только [намного] хуже, скорее всего.
K
Yaroslav Schekin
Только если большинство запросов относятся к небольшому подмножеству partitions (и это можно точно определить на этапе их планирования / выполнения!). Иначе будет только [намного] хуже, скорее всего.
учту, спасибо еще раз.
s
Оперативки бы вам побольше. Явно и csco_ifndq с диска читается и временные файлы для хеша тоже не влезают и на диск пишутся, судя по temp written=2256631
K
Ну и просто вагон перебираемых данных, которые в кеш не влезают и диск насилуют
да, понимаю
s
Yaroslav Schekin
Только если большинство запросов относятся к небольшому подмножеству partitions (и это можно точно определить на этапе их планирования / выполнения!). Иначе будет только [намного] хуже, скорее всего.
Да вроде как как раз скан по периоду дат то как раз самый беспроблемный. БОльшая таблица (и, соответственно, индекс), конечно, ещё сильнее нехватку памяти усугубит, но тут уже гадание сплошное начинается - влезет нужное в кеш или не влезет, вытеснится или не вытеснится.
s
В целом я бы скорее не рассчитывал на эффект
K
но пример с временной таблицей содеражей временной отрезок 2008-2020 (а это самый частый диапазон у дата саентологов) дает прирост существенный даже в текущих условиях.
K
или создать 2 таблицы 1993-2008/2008-2020?
YS
но пример с временной таблицей содеражей временной отрезок 2008-2020 (а это самый частый диапазон у дата саентологов) дает прирост существенный даже в текущих условиях.
Так Вы эту временную таблицу, наверное, ещё как-то ограничиваете (не все поля выбираете, например)?
Вы, кажется, показывали, но я забыл и искать не хочется. ;)
Вы, кажется, показывали, но я забыл и искать не хочется. ;)
B
K
да, точно
s
но пример с временной таблицей содеражей временной отрезок 2008-2020 (а это самый частый диапазон у дата саентологов) дает прирост существенный даже в текущих условиях.
А у вас на основной то все полезные и сработавшие рекомендации умных людей отсюда уже применены чтобы сравнивать равноценно? У вас может изначально эти таблицы тоже целиком читались вообще
K
А у вас на основной то все полезные и сработавшие рекомендации умных людей отсюда уже применены чтобы сравнивать равноценно? У вас может изначально эти таблицы тоже целиком читались вообще
да, нужно анализатор и на них прогнать. после тюна постгреса не проверял.
K
пока жду когда покрывающий индекс большой таблицы создастся
s
да, нужно анализатор и на них прогнать. после тюна постгреса не проверял.
И индексы (если какие-то полезные создавались на частичной таблице) тоже нужно повесить, да. Если индекс по дате будет в память вмещаться и висеть там, то нужные строки по этому критерию выберутся быстро что с партиционированием, что без. Вот если не влезет индекс - вот тогда правильные партиции по дате сократят количество данных, которые нужно будет прочесть с диска.
s
Но до этого лучше не доводить, будет грустно
YS
И индексы (если какие-то полезные создавались на частичной таблице) тоже нужно повесить, да. Если индекс по дате будет в память вмещаться и висеть там, то нужные строки по этому критерию выберутся быстро что с партиционированием, что без. Вот если не влезет индекс - вот тогда правильные партиции по дате сократят количество данных, которые нужно будет прочесть с диска.
Там условие по дате только в одной таблице (не факт, что в другой вообще даты есть).
Т.е. "правильное" партиционирование тут сделать непросто.
И даже в случае партиционирования по датам, выигрыш будет либо тогда, когда при заполнении таблицы происходит много updates/deletes (повторных inserts), либо тогда, когда условия запроса как раз делают выгодным этот индекс по датам не использовать вообще.
Т.е. "правильное" партиционирование тут сделать непросто.
И даже в случае партиционирования по датам, выигрыш будет либо тогда, когда при заполнении таблицы происходит много updates/deletes (повторных inserts), либо тогда, когда условия запроса как раз делают выгодным этот индекс по датам не использовать вообще.
s
BTW, r5.large на 0.03$ дороже (0,126 vs 0,096 USD за час), но оперативки уже не 8гб, а хотя бы 16гб.