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

> Am 16.10.2015 um 12:56 schrieb Thomas Markus <[email protected]>
> 
> Generell ist es wahrscheinlich mathematisch nachvollziehbar, warum der
> Planner hier was anderes wählt. Verteilung der Daten, random <->
> sequential costs, etc. pp.
> 
> Dirty solution (wild guess, um ehrlich zu sein):
> set enable_bitmapscan=off;

Ja, das verhindert die Wahl des Bitmap Heap Scans und das Query ist 
schnell.

Danke, das hilft mir schonmal sehr.

> (in der Session, die diesen Job ausführt natürlich nur!)
> GGfs. auch weitere, im Zweifelsfall wird ja ein SeqScan reichen, wenn du
> das nicht dauernd machst...
> 
> 
> Warum willst du die denn eigentlich sortiert haben, wenn sie eh' 
gelöscht
> werden?

Eigentlich habe ich kein order by explizit verwendet. Das ganze Query 
lautet:

delete from myschema.identifier
where mydate is null
and col1=22083
and trx_id in (select trx_id from myschema.identifier where mydate is null 
and col1=22083 limit 300);


Danke & viele Grüße

Robert