Thread: Re: BUG #1186: Broken Index?

On Fri, Jul 02, 2004 at 04:50:07 -0300,
  PostgreSQL Bugs List <pgsql-bugs@postgresql.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@ns.inter-mic.co.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.

On Fri, 02 Jul 2004 20:50:26 +0200, Edoardo Ceccarelli <eddy@expot.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

Edoardo Ceccarelli <eddy@expot.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@and.org
:0:
* ^From: .*james@and\.org
/dev/null