> 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 > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
