Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как оптимизировать запросы с агрегированием sum
|
|||
|---|---|---|---|
|
#18+
Как оптимизировать запросы с агрегированием sum? Сумма в Postgres работает оч медленно при большом кол-ве записей. Поможет ли установка версии 8.1,сейчас 7.4? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 12:06 |
|
||
|
Как оптимизировать запросы с агрегированием sum
|
|||
|---|---|---|---|
|
#18+
mxlPostgresпри большом кол-ве записейвстречается подход, обзываемый денормализацией. (хранение предварительно подсчитанных по неким поддиапазонам сумм). Правда он эффективен только тогда, когда суммы приложением считаются по некоторым сплошным выборкам, выбираемом всегда в одном и том же порядке, и различающимся разве границами. (Например в бух учете). Иначе таких сумм потребуется считать чрезвычайно много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 12:21 |
|
||
|
Как оптимизировать запросы с агрегированием sum
|
|||
|---|---|---|---|
|
#18+
mxlPostgresКак оптимизировать запросы с агрегированием sum? Сумма в Postgres работает оч медленно при большом кол-ве записей. Поможет ли установка версии 8.1,сейчас 7.4? Не поможет. Индексы при работе с аггрегатными функциями не используются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 12:50 |
|
||
|
Как оптимизировать запросы с агрегированием sum
|
|||
|---|---|---|---|
|
#18+
mxlPostgresКак оптимизировать запросы с агрегированием sum? Сумма в Postgres работает оч медленно при большом кол-ве записей. Поможет ли установка версии 8.1,сейчас 7.4? ИМХО оптимизация только одна - увеличиваем количество памяти выделенной постгресу. А переход на 8.1 с 7.4 делать все равно стоит т.к. улучшений много, и по мелочам набежать может достаточно много ускорений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 14:20 |
|
||
|
Как оптимизировать запросы с агрегированием sum
|
|||
|---|---|---|---|
|
#18+
mxlPostgresКак оптимизировать запросы с агрегированием sum? Сумма в Postgres работает оч медленно при большом кол-ве записей. Поможет ли установка версии 8.1,сейчас 7.4? При большом количестве записей, участвующих в суммировании, или тормозящий эффект создается из-за наличия в таблице большого количества записей, вне зависимости от того, суммируются ли они? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 15:02 |
|
||
|
Как оптимизировать запросы с агрегированием sum
|
|||
|---|---|---|---|
|
#18+
ilejn mxlPostgresКак оптимизировать запросы с агрегированием sum? Сумма в Postgres работает оч медленно при большом кол-ве записей. Поможет ли установка версии 8.1,сейчас 7.4? При большом количестве записей, участвующих в суммировании, или тормозящий эффект создается из-за наличия в таблице большого количества записей, вне зависимости от того, суммируются ли они? Простые выборки (без суммирования) делаются значительно быстрее.В таблице хранятся строки статистики трафика за каждый час и когда получаю сводную таблицу за месяц (уже по дням,то есть суммирование) запрос проходит 1,5 мин (4 млн записей). Как я понял,нужно при добавлении очередной партии строчек проводить INSERT INTO (создавать новую таблицу) и уже из нее брать суммированные данные? Это конечно может немного разгрузить БД,но если нужно смотреть за пред месяц или еще раньше,или суммировать не по дням,а по месяцу? Слышал,что в Oracle есть фишка,что можно разбивать таблицы на части и хранить их как бы отдельно,например,сделать разбитие по месяцам и СУБД будет искать уже только в одной части.Есть ли подобное в Postgres? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 05:41 |
|
||
|
Как оптимизировать запросы с агрегированием sum
|
|||
|---|---|---|---|
|
#18+
авторСлышал,что в Oracle есть фишка,что можно разбивать таблицы на части и хранить их как бы отдельно,например,сделать разбитие по месяцам и СУБД будет искать уже только в одной части. Есть ли подобное в Postgres? http://www.postgresql.org/docs/whatsnew Код: plaintext 1. 2. 3. 4. А вообще согласен с 4321 насчет хранения данных в агрегированом состоянии. Скажем делашь задание ночью, которое группирует данные с шагом 3-6 часов. Затем пишешь хранимку которой передаешь дату начала и конца.. Она все что может считает из агрегированной таблицы + досчитывает из обычной таблицы. Тем более, если интересует в первую очередь статистика по суткам то может оказаться так что эта хранимка будет обращаться только сводной таблицы. + Согласен Andrey Daeron, на сой взгляд PG 8 стал заметно шустрее 7.x.. А в 8.1 обещают еще 20% ускорение по сравнению 8.0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 08:39 |
|
||
|
|

start [/forum/topic.php?fid=53&tid=2006510]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 261ms |
| total: | 402ms |

| 0 / 0 |
