V
я не знаю какое там бд
постгрес
Size: a a a
2020 November 18
АД
ну тогда fragment caching
V
ну тогда fragment caching
тогда когда кеш просрочится при обновлении страницы страница зависнет на 6 секунд. И так будет каждые пять минут (если у кеша 5 мин срок жизни). Это не оч
V
У меня сейчас так
V
ну тогда fragment caching
если я все правильно понял о чем вы говорите
V
тогда когда кеш просрочится при обновлении страницы страница зависнет на 6 секунд. И так будет каждые пять минут (если у кеша 5 мин срок жизни). Это не оч
я думал делать в фоне кроном или sidekiq recurrent job каждые пять минут - и записывать size значение куда нибудь
АД
если я все правильно понял о чем вы говорите
дя, все правильно
АД
вон чо нагуглил
АД
АД
Do you really need count(*)
Sometimes the best solution is to look for an alternative.
Often an approximation is good enough and you don’t need the exact count. In that case you can use the estimate that PostgreSQL uses for query planning:
SELECT reltuples::bigint
FROM pg_catalog.pg_class
WHERE relname = 'mytable';
Sometimes the best solution is to look for an alternative.
Often an approximation is good enough and you don’t need the exact count. In that case you can use the estimate that PostgreSQL uses for query planning:
SELECT reltuples::bigint
FROM pg_catalog.pg_class
WHERE relname = 'mytable';
ND
кто подскажет как это перевести в инт? :key=>"\x00\x00\x00\fi\xF4\xB6\xC7\x9E\x01"
ND
кто подскажет как это перевести в инт? :key=>"\x00\x00\x00\fi\xF4\xB6\xC7\x9E\x01"
я даже знаю что там 166260154
f🤔
ток хотел начать писать почему count(:id) не надо, а там уже
АД
да я не считаю записи обычно - я точно знаю их количество (ц) Чак Норрис
u
Всем привет! У меня есть модель в которой кол-во записей пару миллионов. Можно как то эффективно считать кол-во записей? Какие бест практисес для этого? Не обязательно чтобы колво было точным в реальном времени, достаточно апдейта каждые пять минут
Куча вариантов, на самом деле, все не очень
1) можно завести counter cache
2) завести материализованную вьюху и конкурентно обновлять
3) хранить исторические счётчики в бд, + горячие в редисе (если данные не могут удаляться)
4) можно проверить, точно ли есть индексы подходящие - может и не надо ничего делать будет
5) можно решить вопрос продуктово
6) Считать количество, класть в редис, инкрементировать, раз в н времени пересчитывать с нуля
1) можно завести counter cache
2) завести материализованную вьюху и конкурентно обновлять
3) хранить исторические счётчики в бд, + горячие в редисе (если данные не могут удаляться)
4) можно проверить, точно ли есть индексы подходящие - может и не надо ничего делать будет
5) можно решить вопрос продуктово
6) Считать количество, класть в редис, инкрементировать, раз в н времени пересчитывать с нуля
u
И многое другое) тут надо уже к вам в систему лезть и смотреть
u
Можно вон Давыдову чеканную монету звплатить, и он вам нафигачит сервисов и потоков данных :)
NG
Можно вон Давыдову чеканную монету звплатить, и он вам нафигачит сервисов и потоков данных :)
заплати ты рубииисту
чеканной монееетой
чеканной монееетой
V
Do you really need count(*)
Sometimes the best solution is to look for an alternative.
Often an approximation is good enough and you don’t need the exact count. In that case you can use the estimate that PostgreSQL uses for query planning:
SELECT reltuples::bigint
FROM pg_catalog.pg_class
WHERE relname = 'mytable';
Sometimes the best solution is to look for an alternative.
Often an approximation is good enough and you don’t need the exact count. In that case you can use the estimate that PostgreSQL uses for query planning:
SELECT reltuples::bigint
FROM pg_catalog.pg_class
WHERE relname = 'mytable';
[19] pry(main)> Declaration.all.sizeпомоему очень даже хорошо. В статье говориться что могут быть расхождения на 10 процентов, но помоему это не оч критично в моей ситуации
(4197.0ms) SELECT COUNT(*) FROM "declarations"
=> 4160630
[20] pry(main)> ActiveRecord::Base.connection.execute("SELECT reltuples::bigint FROM pg_catalog.pg_class WHERE relname = 'declarations';").first['reltuples']
(1.3ms) SELECT reltuples::bigint FROM pg_catalog.pg_class WHERE relname = 'declarations';
=> 4056936
V
Куча вариантов, на самом деле, все не очень
1) можно завести counter cache
2) завести материализованную вьюху и конкурентно обновлять
3) хранить исторические счётчики в бд, + горячие в редисе (если данные не могут удаляться)
4) можно проверить, точно ли есть индексы подходящие - может и не надо ничего делать будет
5) можно решить вопрос продуктово
6) Считать количество, класть в редис, инкрементировать, раз в н времени пересчитывать с нуля
1) можно завести counter cache
2) завести материализованную вьюху и конкурентно обновлять
3) хранить исторические счётчики в бд, + горячие в редисе (если данные не могут удаляться)
4) можно проверить, точно ли есть индексы подходящие - может и не надо ничего делать будет
5) можно решить вопрос продуктово
6) Считать количество, класть в редис, инкрементировать, раз в н времени пересчитывать с нуля
в крайнем случае переделаю потом как у вас в 6том варианте