From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Eugeny N Dzhurinsky <bofh(at)redwerk(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Query/database optimization |
Date: | 2006-08-02 03:15:11 |
Message-ID: | 29157.1154488511@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Eugeny N Dzhurinsky <bofh(at)redwerk(dot)com> writes:
> [slow query]
The bulk of your time seems to be going into this indexscan:
> -> Index Scan using task_scheduler_icustomer_id on task_scheduler ts (cost=2.03..11.51 rows=1 width=51) (actual time=2.785..2.785 rows=0 loops=4161)
> Index Cond: ("outer".customer_id = ts.customer_id)
> Filter: ((get_available_pages(task_id, customer_id) > 0) AND ((get_check_period(task_id, next_check) IS NULL) OR ((date_part('epoch'::text, get_check_period(task_id, next_check)) - date_part('epoch'::text, (timenow())::timestamp without time zone)) < 3600::double precision)) AND (status <> 1) AND ((((start_time)::time with time zone < ('now'::text)::time(6) with time zone) AND ((stop_time)::time with time zone > ('now'::text)::time(6) with time zone)) OR ((start_time IS NULL) AND (stop_time IS NULL))) AND (NOT (hashed subplan)))
> SubPlan
> -> Unique (cost=2.02..2.03 rows=1 width=4) (actual time=0.617..0.631 rows=3 loops=1)
> ...
I kinda doubt that the index search itself is that slow --- doubtless
the problem comes from having to evaluate that filter condition on a lot
of rows. How fast are those functions you're calling?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eugeny N Dzhurinsky | 2006-08-02 10:56:22 | Re: Query/database optimization |
Previous Message | Luke Lonergan | 2006-08-02 02:44:20 | Re: XFS filessystem for Datawarehousing -2 |