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
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. . . |