On Sun, 2006-07-09 at 19:52, Neil Hepworth wrote:
> Hi,
>
> I am running PostgreSQL 7.3 on a Linux box (RHEL 2.1 - Xeon 2.8GHz
> with 1GB of RAM) and seeing very high CPU usage (normally over 90%)
> when I am running the following queries, and the queries take a long
> time to return; over an hour!
>
> CREATE TEMPORARY TABLE fttemp1600384653 AS SELECT * FROM ftoneway LIMIT 0;
>
> INSERT INTO fttemp1600384653 SELECT epId, TO_TIMESTAMP(start,
> 'YYYY-MM-DD HH24:00:00.0')::timestamp AS start, 60 AS consolidation,
> SUM(cnt) AS cnt FROM ftone WHERE consolidation = 0 AND start <
> TO_TIMESTAMP('2006-06-27 18:43:27.391103+1000', 'YYYY-MM-DD
> HH24:00:00.0')::timestamp;
I don't need to see an explain analyze to make a guess here...
start < TO_TIMESTAMP('2006-06-27 18:43:27.391103+1000', 'YYYY-MM-DD
HH24:00:00.0')::timestamp
is gonna be a problem because while you and I know that to_timestamp...
is gonna be a constant, pg 7.3 doesn't. I've run into this before.
Just run a query ahead of time with a simple:
select TO_TIMESTAMP('2006-06-27 18:43:27.391103+1000', 'YYYY-MM-DD
HH24:00:00.0')::timestamp as starttime
and then pull that out and stick it into your query. do the same for
any other parts of the query like that.
That's assuming the issue here is that you're getting seq scans cause of
that part of the query.