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

Hans-Jürgen Schönig <[email protected]> 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