Re: [SQL] Re: pgsql-sql-digest V1 #225

From: "Steven M(dot) Wheeler" <swheeler(at)sabre(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-sql(at)hub(dot)org
Subject: Re: [SQL] Re: pgsql-sql-digest V1 #225
Date: 1999-05-26 18:07:13
Message-ID: 374C3851.46D34162@sabre.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Boy is my face red;-}

I just found out that my vacuum has not been running. Once I vacuumed my DB the
performance problems went away. I can now issue a select count(*) from currnt;
and get a response in less than 45 seconds.

Also, I just sent a message to pgsql-admin about performance with pg_dumpall.
Guess what? The vacuum fixed that too. Dumped my 1+GB DB in under 2 minutes (I
didn't time it closely).

Thanks again for all the help.
--
Steven M. Wheeler
UNIX Engineering
The SABRE Group
(918) 292-4119
(918) 292-4165 FAX

Tom Lane wrote:

> "Steven M. Wheeler" <swheeler(at)sabre(dot)com> writes:
> > Regarding your request for a backtrace, I recompiled with debugging and
> > profiling options on. Subsequently I have attached the debugger and
> > interrupted the backend a number of times. I keep coming up in mcount() and
> > a couple of hash functions. BTW: I had let the query run for over 50+ hours
> > without it returning a value. The offending SQL: select count(*) from
> > currnt; Is there something more definitive you would like me to do?
>
> If you could interrupt the backend a few times and provide a full
> backtrace (gdb "bt" command) each time, we could maybe form a picture of
> what the heck it's doing. This report does seem *very* odd, especially
> your discovery that adding a "where" clause speeds it up. (That'd be
> fine if the where clause eliminated many rows, but since it doesn't...)
>
> Also, it would be useful to know what "explain" says about how the query
> will be executed. I'd expect an index scan for the "select ... where"
> case, and a plain sequential scan for the case without where; if it's
> doing something else that would be important to know.
>
> One more thing --- exactly what is the declaration of the currnt table,
> and of its indexes if any?
>
> BTW, I concur with Bruce's suggestion to try a recent 6.5 snapshot.
> I don't see any hashjoin going on here, but it is true that we've
> squashed a remarkable number of bugs between 6.4.* and 6.5. Perhaps
> you are hitting one of them.
>
> regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Fomichev Michael 1999-05-26 20:57:01 Re: [SQL] CASE WHEN / 6.4.2? + no doc in installed documentation
Previous Message JT Kirkpatrick 1999-05-26 17:49:12 select nextval. . .