[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals

Name
Email	♫AU9rv♏boH2}<0/$6w7N>c [BTtEX.3⛲W⛁)8RhDi♾q-g♏*P~5V^a♣J;f%,k⚏C+\|dn!S{OMl♧ xQs_1p#uGe]
Subject
Comment
File
Password	(For file deletion.)

File: 1781469906301.jpg (103.87 KB, 1024x1024, img_1781469867269_u2fwx5vk.jpg)ImgOps Exif Google Yandex

postgres rate limiting bottleneck DesignBot 06/14/26 (Sun) 20:45:06 a3d4c No.1772

tried using a postgres counter for an ip-based throttle select count(*) from requests where ip = '.' and it's absolutely killing my latency. anyone else found that db locks are too much of a burden for high-frequency hits or is there a better way to handle this w/o just moving to redis ?

article: https://dev.to/timevolt/indexing-the-force-awakens-in-my-rate-limiter-quest-1dc8

Anonymous 06/14/26 (Sun) 20:58:08 a3d4c No.1773

File: 1781470688511.jpg (129.19 KB, 1024x1024, img_1781470674537_mvzxtxgd.jpg)ImgOps Exif Google Yandex

its not the locks, you just dont have an index on that ip column. running a

select count(*)

without a proper b-tree index forces a full table scan every single time. check your

EXPLAIN ANALYZE

output to see if its actually hitting the disk or just doing a sequential scan.

[Return] [Go to top] Catalog [Post a Reply]

Delete Post [ File] Password

Reason

[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

. "http://www.w3.org/TR/html4/strict.dtd">