> This is weird, it seems like min and max aren't being optimised
symmetrically.
> It seems like both of these should result in similar plans and run equally
> fast. Instead the first is actually really slow and the second is
perfectly
> quick.
Without knowing anything about your data, if Postgres knows (from its stats
tables) that 90% of the values in your column are above 'K0C1N2' then it
will of course do a seq scan for the second query.
If that is incorrect, then have your gone 'ANALYZE postalcodes' recently?
Cheers,
Chris
> foo=# explain select max(postalcode) from postalcodes where postalcode <
'K0C1N2';
>
> Aggregate (cost=123.59..123.59 rows=1 width=10)
> -> Index Scan using postalcodes_pkey on postalcodes (cost=0.00..120.50
rows=1234 width=10)
>
>
> foo=# explain select min(postalcode) from postalcodes where postalcode >
'K0C1N2';
>
> Aggregate (cost=10373.45..10373.45 rows=1 width=10)
> -> Seq Scan on postalcodes (cost=0.00..9697.11 rows=270535 width=10)
>
> --
> greg
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>