Kromě úspory režijních nákladů spojených s připojením a odpojením, kde se to jinak provádí u každého požadavku, může sdružovač připojení spojit velký počet klientských připojení až na malý počet skutečných databázových připojení. V PostgreSQL je optimální počet aktivních databázových připojení obvykle někde kolem ((2 * core_count) + efektivní_počet_spindle) . Nad tímto číslem se propustnost i latence zhorší.
Někdy lidé řeknou:"Chci podporovat 2000 uživatelů s rychlou dobou odezvy." Je do značné míry zaručeno, že pokud se o to pokusíte s 2000 skutečnými databázovými připojeními, výkon bude hrozný. Pokud máte počítač se čtyřmi čtyřjádrovými procesory a aktivní datový soubor je plně uložen do mezipaměti, uvidíte mnohem lepší výkon pro těchto 2 000 uživatelů, když požadavky propojíte přibližně 35 databázovými připojeními.
Abyste pochopili, proč je to pravda, měl by vám pomoci tento myšlenkový experiment. Zvažte hypotetický počítač databázového serveru s pouze jedním zdrojem ke sdílení -- jediným jádrem. Toto jádro bude časově rovnoměrně rozděleno mezi všechny souběžné požadavky bez režie. Řekněme, že všech 100 požadavků přijde ve stejný okamžik, z nichž každý potřebuje jednu sekundu CPU času. Jádro funguje na všech z nich a dělí mezi ně čas, dokud všechny neskončí o 100 sekund později. Nyní zvažte, co se stane, když do popředí umístíte fond připojení, který bude přijímat 100 klientských připojení, ale na databázový server zadává vždy pouze jeden požadavek a všechny požadavky, které dorazí, když je připojení zaneprázdněné, zařadí do fronty. Nyní, když přijde 100 požadavků současně, jeden klient dostane odpověď za 1 sekundu; další dostane odpověď za 2 sekundy a poslední klient dostane odpověď za 100 sekund. Nikdo nemusel čekat déle, než dostal odpověď, propustnost je stejná, ale průměrná latence je 50,5 sekundy místo 100 sekund.
Skutečný databázový server má více zdrojů, které lze používat paralelně, ale stejný princip platí, jakmile se nasytí, ublížíte věci pouze přidáním více souběžných požadavků na databázi. Ve skutečnosti je to horší než v příkladu, protože s více úlohami máte více přepínačů úloh, zvýšený spor o zámky a mezipaměť, spory o řádky mezipaměti L2 a L3 a mnoho dalších problémů, které snižují propustnost i latenci. Navíc s vysokým work_mem nastavení může pomoci dotazu mnoha způsoby, toto nastavení je limit na uzel plánu pro každé připojení , takže při velkém počtu připojení musíte toto ponechat velmi malé, abyste se vyhnuli vyprázdnění mezipaměti nebo dokonce swapování, které vede k pomalejším plánům nebo takovým věcem, jako je přelévání hashovacích tabulek na disk.
Některé databázové produkty efektivně zabudují do serveru fond připojení, ale komunita PostgreSQL zaujala stanovisko, že protože nejlepší sdružování připojení se provádí blíže ke klientskému softwaru, nechají na uživatelích, aby to spravovali. Většina poolerů bude mít nějaký způsob, jak omezit databázová připojení na pevný počet a zároveň povolit více souběžných požadavků klientů než to, a podle potřeby je zařadit do fronty. To je to, co chcete, a mělo by to být provedeno na transakčním na základě, nikoli podle příkazu nebo spojení.