Ik heb je vraagplan op explain.depesz.com geplaatst, kijk eens.
De schattingen van de queryplanner zijn op sommige plaatsen vreselijk verkeerd. Heeft u ANALYZE uitgevoerd onlangs?
Lees de hoofdstukken in de handleiding Statistieken gebruikt door de Planner en Planner Kostenconstanten. Besteed speciale aandacht aan de hoofdstukken over random_page_cost en default_statistics_target .
Je zou kunnen proberen:
ALTER TABLE diplomas ALTER COLUMN number SET STATISTICS 1000;
ANALYZE diplomas;
Of ga nog hoger voor een tafel met 10 miljoen rijen. Het hangt af van de gegevensdistributie en feitelijke zoekopdrachten . Experiment. Standaard is 100, maximum is 10000.
Voor een database van die grootte, slechts 1 of 5 MB work_mem zijn over het algemeen niet voldoende. Lees de Postgres Wiki-pagina op Tuning Postgres waar @aleroot naar linkte.
Aangezien uw vraag 430104kB geheugen op schijf nodig heeft volgens EXPLAIN uitvoer, moet u work_mem . instellen naar iets als 500MB of meer om in-memory sorteren mogelijk te maken. In-memory weergave van gegevens heeft wat meer ruimte nodig dan weergave op schijf. Misschien ben je geïnteresseerd in wat Tom Lane onlangs over die kwestie heeft gepost.
Verhogen van work_mem een klein beetje, zoals je hebt geprobeerd, zal niet veel helpen of zelfs vertragen. Wereldwijd hoog instellen kan zelfs pijn doen, vooral bij gelijktijdige toegang. Meerdere sessies kunnen elkaar verhongeren voor middelen. Als u meer voor één doel toewijst, neemt het geheugen van een ander doel weg als de bron beperkt is. De beste opstelling hangt af van de volledige situatie.
Om bijwerkingen te voorkomen, stelt u deze alleen lokaal hoog genoeg in uw sessie in, en tijdelijk voor de vraag:
SET work_mem = '500MB';
Zet het daarna terug naar je standaard:
RESET work_mem;
Of gebruik SET LOCAL om het in te stellen voor de huidige transactie om mee te beginnen.