On Sun, Nov 27, 2005 at 11:38:57PM +1100, Brendan Jurd wrote:
> > Already done in 8.1. Here's an excerpt from the Release Notes:
> >
> > Automatically use indexes for MIN() and MAX() (Tom)
> >
> > In previous releases, the only way to use an index for MIN()
> > or MAX() was to rewrite the
> Already done in 8.1. Here's an excerpt from the Release Notes:
>
> Automatically use indexes for MIN() and MAX() (Tom)
>
> In previous releases, the only way to use an index for MIN()
> or MAX() was to rewrite the query as SELECT col FROM tab ORDER
> BY col LIMIT 1. Index usage now
On Mon, Oct 24, 2005 at 16:21:57 -0700,
[EMAIL PROTECTED] wrote:
> On Mon, Oct 24, 2005 at 07:14:43PM -0400, Alex Turner wrote:
> > I believe based on semi-recent posts that MIN and MAX are now treated
> > as special cases in 8.1, and are synonymous with select id order by id
> > desc limit 1 etc
On Mon, Oct 24, 2005 at 03:50:57PM -0700, [EMAIL PROTECTED] wrote:
> I can't see any difference between these two statements:
>
> SELECT MAX(id) FROM table;
> SELECT id FROM table ORDER BY id DESC LIMIT 1;
>
> If the planner / optimizer / whatever doesn't optimize them to the
> same end r
On Mon, Oct 24, 2005 at 07:14:43PM -0400, Alex Turner wrote:
> I believe based on semi-recent posts that MIN and MAX are now treated
> as special cases in 8.1, and are synonymous with select id order by id
> desc limit 1 etc..
Aha! I looked it up in the release notes, you are right. I had never
I believe based on semi-recent posts that MIN and MAX are now treated
as special cases in 8.1, and are synonymous with select id order by id
desc limit 1 etc..
Alex
On 10/24/05, Douglas McNaught <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > However, in the process of investigating
[EMAIL PROTECTED] writes:
> However, in the process of investigating this, my boss found something
> which we do not understand. A table with a primary key 'id' takes 200
> seconds to SELECT MAX(id), but is as close to instantaneous as you'd
> want for SELECT ID ORDER BY ID DESC LIMIT 1. I under
Dang, that's a lot of answer! :-) and not what I was hoping for. Max
and count both have to look up data records to skip values associated
with other transactions. But count, by definition, has to scan every
single record from one end of the index to the other, so the index is
useless, whereas ma
On Mon, 2005-10-24 at 16:57, [EMAIL PROTECTED] wrote:
> Having been surprised a few times myself by EXPLAIN showing a
> sequential scan instead of using an index, and having seen so many
> others surprised by it, I hope I am not asking a similar question.
>
> We recently upgraded our db servers, b
Having been surprised a few times myself by EXPLAIN showing a
sequential scan instead of using an index, and having seen so many
others surprised by it, I hope I am not asking a similar question.
We recently upgraded our db servers, both old and new running 8.0, and
one casualty was forgetting to
10 matches
Mail list logo
