[EMAIL PROTECTED] writes:
> and the query that I would like to run is:
> SELECT e1.endnode, count(*), sum(e1.weight) AS weight1, sum(e2.weight)
> AS weight2
> FROM event e1, event e2
> WHERE e1.endnode = e2.startnode AND e1.starttime < e2.starttime AND
> e2.starttime < e1.endtime
> GROUP BY e1.end
I'm doing a self join of some shipping data and wanted to get the best
query possible. The interesting table is the event table, and it has
the following structure:
startnode int,
endnode int,
weight int,
starttime timestamp,
endtime timestamp
and the query that I would like to run is:
"Craig A. James" <[EMAIL PROTECTED]> writes:
> It's also possible that the INSERT itself is the problem, or adds to the
> problem. The SIGINT may come after a few million rows have been inserted, so
> it would have to clean that up, right?
No, because we don't use UNDO. The next VACUUM would h
Tom Lane wrote:
"Craig A. James" <[EMAIL PROTECTED]> writes:
Bottom line is that I was expecting "instant death" with SIGTERM, but
instead got an agonizing, drawn out -- but safe -- death of the query.
What was the query exactly?
Our expectation is that all or at least most queries should res
Hi, Tom,
Tom Lane wrote:
> Our expectation is that all or at least most queries should respond to
> SIGINT or SIGTERM interrupts pretty rapidly, say on a less-than-a-second
> timescale. However there are various loops in the backend that fail to
> execute CHECK_FOR_INTERRUPTS sufficiently often :
* Greg Stark:
> Didn't byteas used to get printed as hex?
No, they didn't. It would be useful to support hexadecimal BYTEA
literals, though. Unfortunately, X'DEADBEEF' has already been taken
by bit strings.
--
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH htt
