Re: slow plan for min/max - Mailing list pgsql-performance

From Matt Clark
Subject Re: slow plan for min/max
Date
Msg-id LFEIJBEOKGPDHCEMDGNFEEGGCAAA.matt@ymogen.net
Whole thread Raw
In response to Re: slow plan for min/max  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: slow plan for min/max
Re: slow plan for min/max
List pgsql-performance
>This is a Frequently asked question about something that isn't likely to
>change any time soon.

You're right, it is in the FAQ, but pretty well buried.  It is entirely
non-obvious to most people that min() and max() don't/can't use indices.
Something so counterintuitive should be explicitly and prominently
advertised, especially since the "order by X limit 1" workaround is so
simple.

Actually, referring down to later parts of this thread, why can't this
optimisation be performed internally for built-in types?  I understand the
issue with aggregates over user-defined types, but surely optimising max()
for int4, text, etc is safe and easy?

Of course I may be so far out of my depth as to be drowning, in which case
please put me out of my misery.

M


pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: slow plan for min/max
Next
From: "Matt Clark"
Date:
Subject: Re: slow plan for min/max