From: | Dmitry Tkach <dmitry(at)openratings(dot)com> |
---|---|
To: | Paulo Jan <admin(at)digital(dot)ddnet(dot)es> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Index not being used in MAX function (7.2.3) |
Date: | 2003-06-10 18:07:43 |
Message-ID: | 3EE61E6F.6040205@openratings.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Yep. It's a "feature" :-)
I had hard time understanding why too...
Apparently, there is nothing special about max() aggregate from the
query planner's standpoint, compared to any other aggregate function. It
doesn't know its specifics, and thus is not able to figure out that all
it really needs is to grab the first entry from the index...
To mak it quicker do this instead:
select id from todocinetv order by id desc limit 1;
I hope, it helps...
Dima
Paulo Jan wrote:
> Hi all:
>
> I have here a table belonging to a message board (Phorum 3.3), and
> there's an index in it that is not being used for reasons that I don't
> understand. The table is:
>
>
> Table "todocinetv"
> Column | Type | Modifiers
> -------------+-----------------------------+----------------------
> id | integer | not null default '0'
> datestamp | timestamp without time zone | not null
> thread | integer | not null default '0'
> parent | integer | not null default '0'
> author | character(37) | not null default ''
> subject | character(255) | not null default ''
> email | character(200) | not null default ''
> attachment | character(64) | default ''
> host | character(50) | not null default ''
> email_reply | character(1) | not null default 'N'
> approved | character(1) | not null default 'N'
> msgid | character(100) | not null default ''
> modifystamp | integer | not null default '0'
> userid | integer | not null default '0'
> Indexes: todocinetv_approved,
> todocinetv_author,
> todocinetv_datestamp,
> todocinetv_modifystamp,
> todocinetv_msgid,
> todocinetv_parent,
> todocinetv_subject,
> todocinetv_thread,
> todocinetv_userid,
> todocinetvpri_key
>
>
> And the index "todocinetvpri_key" is created on the primary key
> (id). Yet when I do:
>
> explain select max(id) from todocinetv;
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=30939.22..30939.22 rows=1 width=4)
> -> Seq Scan on todocinetv (cost=0.00..30882.98 rows=22498 width=4)
>
>
> It doesn't use the index, and surely, it takes forever. I have
> tried with VACUUM ANALYZE, and also dropping the index, creating it
> again and VACUUMing it, and it never uses it. The only explanation I
> can come up with is that the MAX() function doesn't use indices; I
> have tried with tables in other databases (running Postgres 7.2.1),
> and it doesn't use the indices in any of them.
> Is this the right behaviour? Or there is something else going on?
> The table mentioned above is in a Postgres 7.2.3 server, while the
> other ones that I used for testing were, as I said, in 7.2.1.
>
>
>
> Paulo Jan.
> DDnet.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Gearon | 2003-06-10 18:13:18 | Re: [GENERAL] MySQL gets $19.5 MM |
Previous Message | Dmitry Tkach | 2003-06-10 18:03:37 | Weird postmaster crashes |