Re: Query Planner wählt langsamen Bitmap Heap Scan statt Index Scan bei Limit

Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> schrieb am 16.10.2015 14:53:38:

> das verhalten, das du siehst, ist ganz natürlich.
> irgendwann sieht der optimizer, dass du immer mehr und mehr blöcke aus
der tabelle benötigst. dem versucht er mit einem bitmap
> scan entgegen zu wirken, weil er annimmt, dass der index aufgrund von
immer mehr random I/O für ihn geschätzt zu teuer wird.
> real muss das nicht sein - kann aber sein (je nach caching, correlation
on disk, etc.).
> im prinzip gibts drei methoden:

Ja. Das leuchtet ein.

> a.) set enable_bitmapscan TO off … und hoffen, dass er beim index
bleibt.
> b.) set random_page_cost TO 1; … das macht random I/O relativ zur
sequential I/O billiger und sollte ihn länger auf index scna halten
> c.) versuch es mal mit einem sequential scan. wenn du genug daten
löscht, kann das durchaus auch schneller sein
>

Super. Danke für die vielen Vorschläge. Ich habe die Lösung a) gewählt,
das sie mich schnell zum Ziel führt.

> ein sequential scan ist bei solchen dingen oft gar nicht so schlecht wie
sein ruf.
> in summe ist es halt so, dass der planner die abschätzungen macht und
entsprechend dem kostenmodell handelt.
> das kostenmodell ist natürlich nur bedingt real.

Guter Hinweis. Ich werde das für zukünftige Probleme im Hinterkopf
behalten.

Viele Dank für die prompte Hilfe

Robert