|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
05.10.2017, 16:23
|
|||
|---|---|---|---|
|
|||
кэширование запросов |
|||
|
#18+
Умеет ли Posgresql кэшировать результаты запросов? Есть приложение логика работы которого неизвестна. Известно лишь что оно генерирует кучу запросов представляющих собою чистый селект без каких-либо условий. Выполняется он в среднем порядка допустим 0,5 сек. и примерно 100000 раз в сутки. Данные в таблице изменяются достаточно редко (несколько раз в сутки). Есть ли какое-либо решение позволяющее закэшировать результаты запроса, чтобы не выполнять его каждый раз. Изменить логику работы приложения пока нет возможности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.10.2017, 17:06
|
|||
|---|---|---|---|
кэширование запросов |
|||
|
#18+
mism, query cache подобно тому который был в mysql - нет. Кеширует странички запрашиваемые с диска в shared_buffers. mismчистый селект без каких-либо условий. Выполняется он в среднем порядка допустим 0,5 сек Сделайте explain (analyze,buffers) для запроса который делает приложение (лучше с включенным track_io_timing). Если будет видно что долго читаем с диска - добавление shared_buffers поможет. Если всё и так в памяти и в запросе просто глупый seq scanверхней и единственной операцией - вы упёрлись в передачу данных и никакое кеширование на стороне базы вам с этим не поможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.10.2017, 17:26
|
|||
|---|---|---|---|
|
|||
кэширование запросов |
|||
|
#18+
"Если всё и так в памяти и в запросе просто глупый seq scan" "Seq Scan on hsvarstatus (cost=0.00..4798.05 rows=310805 width=7) (actual time=0.007..92.528 rows=311274 loops=1) Buffers: shared hit=1690 Planning time: 0.346 ms Execution time: 204.235 ms" Получается что ничего не поможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.10.2017, 21:29
|
|||
|---|---|---|---|
|
|||
кэширование запросов |
|||
|
#18+
mism, есть такое чудо заморское . правда не использую и не использовал. когда-то задавал такие самые вопросы, и пока искал ответы, наткнулся на это. но переосмыслив, понял, что по крайней мере в моём случае, это ружьё нацеленое на мою ногу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.10.2017, 22:55
|
|||
|---|---|---|---|
кэширование запросов |
|||
|
#18+
mism, Судя по плану, у вас там что-то типа `SELECT * FROM hsvarstatus`, которая размером ~ 13Мб. Такие данные надо кэшировать на стороне приложения или в стороннем продукте. redis? memcached? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.10.2017, 04:48
|
|||
|---|---|---|---|
|
|||
кэширование запросов |
|||
|
#18+
mism"Если всё и так в памяти и в запросе просто глупый seq scan" "Seq Scan on hsvarstatus (cost=0.00..4798.05 rows=310805 width=7) (actual time=0.007..92.528 rows=311274 loops=1) Buffers: shared hit=1690 Planning time: 0.346 ms Execution time: 204.235 ms" Получается что ничего не поможет. учитывая что на базе он 200ms выполняется то большую часть времени занимает не выполнение запроса а передача 13Mb ответа по сети что дело небыстрое в любом случае. И никакой query cache тут не поможет. А вот 10Gbit сеть между базой и приложением - может помочь. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.10.2017, 15:09
|
|||
|---|---|---|---|
|
|||
кэширование запросов |
|||
|
#18+
"А вот 10Gbit сеть между базой и приложением - может помочь." Там и так уже 10Gbit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.10.2017, 09:05
|
|||
|---|---|---|---|
|
|||
кэширование запросов |
|||
|
#18+
mism... приложение ... генерирует кучу запросов ... примерно 100000 раз в сутки... actual rows=311274Ну пусть разработчики приложения и меняют у себя логику. Каждую секунду запрашивают 300К строк, причем редко меняющихся. Даже слов нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=53&tablet=1&tid=1996182]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 301ms |
| total: | 441ms |
| 0 / 0 |
