finding a max value

The following bug has been logged online:

Bug reference: 1186
Logged by: Gosen, Hitoshi

Email address: mic-gosen(at)ns(dot)inter-mic(dot)co(dot)jp

PostgreSQL version: 7.4

Operating system: linux 2.4.18

Description: Broken Index?

Details:

Hello All,
We are using PostgreSQL 7.4.2 for our website that handles over 200,000
transactions a day.
About a month ago, the responses from the SELECT queries on the database
became terribly slow.
We tried to anaylze the cause of the problem, searching throught the system
logs and all, but nothing appeared to be out of the ordinary.

What we did to resolve this was to dump the database, delete the database,
recreate the database, and finally restore it. After that, things were back
to normal.

From the above experience, we were able to hypothesize that the fault of the
slow responses was not from a broken data or hardware failures, but from a
broken index, since we were able to recover 100% of the data on the same
machine.

Today, the same problem occured, and the same actions are going to be taken
to temporary resolve it.

Final note: we will also experiment with the 'vacuum full' command to see
if it counters this problem.

On Fri, Jul 02, 2004 at 04:50:07 -0300,
PostgreSQL Bugs List <pgsql-bugs(at)postgresql(dot)org> wrote:
>
> The following bug has been logged online:

This doesn't appear to be a bug at this point. It sounds like you have
a self induced performance problem, so I am moving the discussion to
pgsql-performance.

>
> Bug reference: 1186
> Logged by: Gosen, Hitoshi
>
> Email address: mic-gosen(at)ns(dot)inter-mic(dot)co(dot)jp
>
> PostgreSQL version: 7.4
>
> Operating system: linux 2.4.18
>
> Description: Broken Index?
>
> Details:
>
> Hello All,
> We are using PostgreSQL 7.4.2 for our website that handles over 200,000
> transactions a day.
> About a month ago, the responses from the SELECT queries on the database
> became terribly slow.
> We tried to anaylze the cause of the problem, searching throught the system
> logs and all, but nothing appeared to be out of the ordinary.
>
> What we did to resolve this was to dump the database, delete the database,
> recreate the database, and finally restore it. After that, things were back
> to normal.
>
> From the above experience, we were able to hypothesize that the fault of the
> slow responses was not from a broken data or hardware failures, but from a
> broken index, since we were able to recover 100% of the data on the same
> machine.
>
> Today, the same problem occured, and the same actions are going to be taken
> to temporary resolve it.
>
> Final note: we will also experiment with the 'vacuum full' command to see
> if it counters this problem.

It sounds like you aren't properly vacuuming your database. It is possible
that you need a higher FSM setting or to vacuum more frequently.

This is the query:
select max(KA) from annuncio

field KA is indexed and is int4,

explaining gives:
explain select max(KA) from annuncio;
QUERY PLAN
-----------------------------------------------------------------------
Aggregate (cost=21173.70..21173.70 rows=1 width=4)
-> Seq Scan on annuncio (cost=0.00..20326.76 rows=338776 width=4)
(2 rows)

wasn't supposed to do an index scan? it takes about 1sec to get the result.

PostgreSQL Bugs List wrote:
> Hello All,
> We are using PostgreSQL 7.4.2 for our website that handles over 200,000
> transactions a day.
> About a month ago, the responses from the SELECT queries on the database
> became terribly slow.
> We tried to anaylze the cause of the problem, searching throught the system
> logs and all, but nothing appeared to be out of the ordinary.
>
> What we did to resolve this was to dump the database, delete the database,
> recreate the database, and finally restore it. After that, things were back
> to normal.
>
> From the above experience, we were able to hypothesize that the fault of the
> slow responses was not from a broken data or hardware failures, but from a
> broken index, since we were able to recover 100% of the data on the same
> machine.
>
> Today, the same problem occured, and the same actions are going to be taken
> to temporary resolve it.
>
> Final note: we will also experiment with the 'vacuum full' command to see
> if it counters this problem.

This is not for sure a bug, but a known behaviour if you don't vacuum at all
your db. I bet you don't use the vacuum daemon; use it or schedule a simple
vacuum on the eavily updated table each 10 minutes. I strongly suggest you to use
the autovacuum daemon.

Do not esitate to ask how use it.

Regards
Gaetano Mendola

Edoardo Ceccarelli <eddy(at)expot(dot)it> writes:

> This is the query:
> select max(KA) from annuncio
>
> field KA is indexed and is int4,
>
> explaining gives:
> explain select max(KA) from annuncio;
> QUERY PLAN
> -----------------------------------------------------------------------
> Aggregate (cost=21173.70..21173.70 rows=1 width=4)
> -> Seq Scan on annuncio (cost=0.00..20326.76 rows=338776 width=4)
> (2 rows)
>
>
> wasn't supposed to do an index scan? it takes about 1sec to get the result.

This is a known misfeature of max() in postgresql, see...

http://archives.postgresql.org/pgsql-performance/2003-12/msg00283.php

--
# James Antill -- james(at)and(dot)org
:0:
* ^From: (dot)*james(at)and\(dot)org
/dev/null

On Fri, 02 Jul 2004 20:50:26 +0200, Edoardo Ceccarelli <eddy(at)expot(dot)it> wrote:

> This is the query:
> select max(KA) from annuncio

> wasn't supposed to do an index scan? it takes about 1sec to get the result.

> TIP 5: Have you checked our extensive FAQ?

I believe this is a FAQ.

See: http://www.postgresql.org/docs/faqs/FAQ.html#4.8

Try "select KA from annuncio order by KA desc limit 1;"

/rls

--
:wq