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

> Am 16.10.2015 um 12:56 schrieb Thomas Markus <t(dot)markus(at)proventis(dot)net>
>
> 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