"Steven M. Wheeler" <swheeler@sabre.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