ome direction to this problem.
Thanks.
Tom Lane <[EMAIL PROTECTED]> wrote:
Abu Mushayeed writes:
> The query is as follows and it's explain plan is also attached:
The query itself seems to be a simple join over not too many rows, so
I don't see how it could be taking 24 ho
0 disk page fetches is a bit, but it shouldn't take 24 hours. There's
probably misestimation involved at some point here. Does it really return 267
rows, or many more?
It returns finally about 19-20 thousand rows.
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:
On Fri,
I have an interesting problem. I have the following query that ran ok on Monday
and Tuesday and it has been running ok since I have been at this job. I have
seen it to be IO intensive, but since Wednesday it has become CPU intensive.
Database wise fresh data has been put into the tables, vacuume
1. The function:
SELECT a.birth_date FROM (
SELECT indiv_fkey, birth_dt as birth_date, intern_last_update::date as
last_update, 'fed' as source
FROM cdm.cdm_fedcustomer
WHERE birth_dt IS NOT NULL
AND indiv_fkey = $1
UNION
SELECT indiv_fkey, birthdate as birth_date, last_up
Following is one of the update query and it's explain plan which takes about 6
mins to execute. I am trying to find a way to execute it faster. The functions
used in the update statement are if then else test and then return one value or
the other.
===
I have partitioned a table based on period (e.g., cdate >= '2007-01-01'::date
and cdate<=.2007-03-31':;date).
Now, I am issuing query like cdate >= CURRENT_DATE - 1 and cdate <=
CURRENT_DATE, it scans all the partitions. But if I do cdate >=
'2007-01-01'::date and cdate<=.2007-03-31'::date it p
