For the first two queries all it has to do is scan in the clustered index to the first entry for that value of `IDUkazatel` - because of the order of the index that row will be the lowest value for cas for that value of `IDUkazatel`.

In the second query this optimisation is not value and it is probably seeking to the first row for `IDUkazatel=24` then scanning down the index until the last row with `IDUkazatel=25` to find the minimum value of `cas` over all those rows.

If you hover over that fat arrow you'll see it is reading many rows (certainly all those for 24, probably all those for 25 too), whereas the thin arrows in the plan output for the other two show the `top` action causing it to only consider one row.

You could try run each query and then get the minimum for the minimums found:

    SELECT MIN(cas)
    FROM   (
            SELECT cas=MIN(cas) FROM PenData p WHERE p.IDUkazatel = 24
            UNION ALL
            SELECT cas=MIN(cas) FROM PenData p WHERE p.IDUkazatel = 25
        ) AS minimums

That said, it seems you have a table with `IDUkazatel` values rather than an explicit `OR` clause. The code below will work with that arrangement, simply replace the table name `@T` with the name of the table containing `IDUkazatel` values:

    SELECT 
        MinCas = MIN(CA.PartialMinimum)
    FROM @T AS T
    CROSS APPLY 
    (
        SELECT 
            PartialMinimum = MIN(PD.Cas)
        FROM dbo.PenData AS PD
        WHERE 
            PD.IDUkazatel = T.IDUkazatel
    ) AS CA;

In an ideal world, the SQL Server query optimizer would perform this rewrite for you, but it does not always consider this option today.